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Abstract 

In  some  situations,  users  need  to  authenticate  as  distinct  members  of  some  well- 
defined  group,  without  revealing  their  individual  identities:  to  validate  and  corroborate 
a  leak,  for  example,  or  to  count  participants  in  a  closed  anonymous  forum.  Current 
group  authentication  techniques  offering  this  capability,  however,  may  de-anonymize 
users  if  an  attacker  later  compromises  their  private  keys.  Addressing  this  under-explored 
risk,  we  present  deniable  anonymous  group  authentication  (DAG A),  the  first  anonymous 
authentication  protocol  offering  proportionality ,  forward  anonymity ,  and  deniability  in 
combination.  To  offer  these  properties,  DAGA  leverages  a  federation  of  collectively 
(but  not  individually)  trusted  servers.  These  servers  collectively  generate  tags  during 
authentication,  which  ensure  client  distinctness  and  proportionality,  while  cryptograph¬ 
ically  scrubbing  information  that  could  later  de-anonymize  clients.  After  an  authenti¬ 
cation  round,  clients  and  (honest)  servers  securely  erase  their  ephemeral  secrets,  pro¬ 
tecting  clients  from  later  de-anonymization  even  if  an  attacker  eventually  compromises 
all  long-term  client  and  server  keys.  A  proof-of-concept  prototype  validates  DAGA’s 
practicality,  authenticating  a  client  into  a  32-member  group  in  one  second,  or  into  a 
2048-member  group  in  two  minutes. 


1  Introduction 


In  privacy-sensitive  communications,  one  user  sometimes  needs  to  prove  to  be  a  member 
of  some  explicit,  well-defined  group,  without  revealing  his  individual  identity.  Consider  for 
example  a  whistleblower  who  wishes  to  leak  evidence  of  corporate  or  government  wrongdoing 
to  a  journalist,  via  an  anonymous  electronic  “drop  box”  |23|.  The  journalist  needs  to 
validate  the  source’s  trustworthiness,  but  the  whistleblower  is  reluctant  to  reveal  his  identity 
for  fear  their  communications  might  be  compromised  34],  or  that  the  journalist  will  be 
coerced  into  testifying  against  the  source  52  .  The  whistleblower  thus  wishes  to  authenticate 


anonymously  as  a  member  of  some  authoritative  circle  who  plausibly  has  knowledge  of  and 
access  to  the  leaked  information,  such  as  a  corporate  board  member  or  executive,  or  a 
government  official  of  a  given  rank. 

Even  if  the  whistleblower  convinces  the  journalist  of  his  authority,  the  journalist  may  also 
require  corroboration',  e.g.,  confirmation  by  one  or  more  other  members  of  this  authoritative 
circle  that  the  leaked  information  is  genuine.  Other  members  of  this  authoritative  circle  may 


*This  material  is  based  upon  work  supported  by  the  Defense  Advanced  Research  Agency  (DARPA)  and 
SPAWAR  Systems  Center  Pacific,  Contract  No.  N66001-11-C-4018. 
f  Department  of  Computer  Science,  Yale  University,  CT 
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be  just  as  reluctant  to  communicate  with  the  journalist,  however.  If  a  potential  corroborator 
also  demands  anonymity,  how  can  the  journalist  (or  the  public)  know  that  the  corroborator 
is  indeed  a  second  independent  source,  and  not  just  the  original  source  wearing  a  second 
guise?  In  general,  if  the  journalist  knows  k  pseudonymous  group  members,  how  can  he 
know  that  these  pseudonyms  proportionally  represent  k  real,  distinct  group  members,  and 
are  not  just  k  Sybil  identities  26  ? 

Finally,  the  whistleblower  is  concerned  that  once  the  leak  becomes  public,  he  may  be 
placed  under  suspicion  -  perhaps  merely  for  being  in  the  relevant  authoritative  circle  -  and 
any  of  his  computing  devices  may  be  confiscated  or  compromised  along  with  his  private 
keys.  Even  if  his  keys  are  compromised,  the  whistleblower  needs  his  anonymity  forward 
protected,  against  both  the  journalist  and  any  third-parties  who  might  have  observed  their 
communications.  Further,  the  whistleblower  wishes  to  be  able  to  deny  having  even  par¬ 
ticipated  in  any  sensitive  communication,  including  the  fact  of  having  authenticated  at  all 
(even  anonymously)  to  the  journalist. 

We  present  deniable  anonymous  group  authentication  (DAG A),  the  first  protocol  we 
are  aware  of  satisfying  the  above  requirements,  which  we  term  anonymity ,  proportionality , 
forward  anonymity ,  and  deniability.  Like  ring  signatures  |50],  DAG  A  allows  a  user  to  au¬ 
thenticate  as  an  anonymous  member  of  an  ad  hoc  group  or  ring,  defined  by  an  arbitrary  list 
of  public  keys.  The  user  can  conscript  other  users  into  a  group  without  their  participation, 
consent,  or  even  knowledge.  Neither  ring  signatures  nor  deniable  ring  authentication  |47 
offer  proportionality,  however:  a  verifier  cannot  tell  whether  several  authentications  were 
by  the  same  or  distinct  group  members.  Linkable  ring  signatures  1 44  include  a  tag  en¬ 
abling  a  verifier  to  check  distinctness,  but  anyone  who  later  compromises  the  user’s  private 
key  can  reproduce  the  linkage  tags  in  all  past  signatures,  violating  forward  anonymity  and 
deniability.  It  appears  likely  that  no  purely  offline  anonymous  signature  scheme  can  of¬ 
fer  both  proportionality  (corroboration  capability),  forward  anonymity,  and  deniability  in 
combination. 

To  resolve  these  apparently  conflicting  requirements,  DAGA  relies  on  a  federation  of 
independently  operated  servers  that  are  collectively  but  not  individually  trusted.  DAGA’s 
security  property  properties  are  ensured  as  long  as  at  least  one  server  operates  correctly  and 
honestly  during  an  authentication  process,  even  if  the  client  does  not  know  which  server  is 
honest.  The  servers  divide  authentication  activity  into  epochs,  choosing  a  set  of  fresh  server- 
side  secrets  for  each  epoch.  These  secrets  collectively  protect  the  relationship  between  a 
client’s  private  key  and  the  epoch-specific  tags  that  DAGA  produces  to  offer  proportionality 
and  corroboration  capability.  After  each  epoch,  the  honest  server(s)  securely  erase  their 
secrets,  preventing  anyone  from  compromising  any  client’s  anonymity  in  past  authentication 
epochs  -  even  if  the  attacker  later  compromises  the  long-term  private  keys  of  all  clients 
and  all  servers.  Finally,  the  authentication  process  offers  deniability  by  employing  only 
interactive  zero-knowledge  proofs,  ensuring  that  any  valid  DAGA  communication  transcript 
could  have  been  synthesized  independently  by  anyone. 

We  have  analyzed  and  verified  DAGA’s  four  key  security  properties  of  anonymity,  pro¬ 
portionality,  forward  anonymity,  and  deniability.  We  have  also  built  a  working  proof-of- 
concept  implementation  of  DAGA  to  validate  its  performance  and  practical  usability.  Us¬ 
ing  2048-bit  DSA  keys,  our  DAGA  prototype  can  authenticate  as  a  member  of  a  32-member 
group  to  2  servers  in  about  one  second  after  consuming  less  than  1KB  of  total  messaging 
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bandwidth.  Authenticating  in  a  2048-member  group  takes  about  two  minutes  and  con¬ 
sumes  about  100KB  of  bandwidth.  Our  initial  prototype  is  currently  unoptimized,  and  we 
expect  its  performance  and  efficiency  can  be  improved  in  many  ways.  Nevertheless,  our 
results  suggest  that  DAGA  is  already  practical  for  sensitive  anonymous  interactions  re¬ 
quiring  maximum  security,  and  we  believe  DAGA’s  unique  combination  of  proportionality 
(corroboration),  forward  anonymity,  and  deniability  features  can  justify  this  cost  in  such 
scenarios. 

This  paper  makes  the  following  key  contributions: 

1)  proposes  a  new  authentication  scheme  that  offers  anonymity,  deniability,  and  propor¬ 
tionality  even  in  the  case  of  a  full  compromise  of  private  keys  (Section  [4]), 

2)  proposes  an  authentication  scheme  that  supports  evolving  groups  while  preserving 
proportionality, 

3)  separates  the  notions  of  deniability,  anonymity  and  forward  anonymity,  and  analyzes 
these  security  properties. 

Section  [2]  offers  an  overview  of  DAGA’s  trust  model,  operation,  and  security  properties. 
Section  [3]  outlines  several  applications  for  which  DAGA  might  be  suited.  Section  [4]  presents 
the  details  of  the  DAGA  protocol.  Section  [5]  outlines  potentially  useful  extensions  to  the 
basic  protocol,  and  Section  [6]  outlines  practical  implementation  and  deployment  consid¬ 
erations.  Section  [7]  presents  our  prototype  implementation  and  experimental  results,  and 
Section  [8]  summarizes  DAGA’s  formal  security  properties  and  briefly  sketches  our  proofs  of 
these  properties.  Finally,  Section  [9]  outlines  related  work,  and  Section  IT  concludes. 


2  Overview 


2.1  Trust  Model 


We  assume  an  anytrust  1 60 , 61  model,  where  there  is  a  large  set  of  n  clients  and  a  smaller 


set  of  m  reliable  servers,  which  includes  at  least  one  honest  server  that  runs  the  prescribed 
protocols  and  does  not  collude  with  dishonest  entities.  The  clients  do  not  need  to  assume 
that  any  particular  server  is  trustworthy;  they  need  only  trust  that  some  honest  server 
exists.  We  further  assume  that  there  are  always  at  least  two  honest  clients;  anonymity  is 
trivially  impossible  if  n  —  1  clients  choose  to  collude  against  only  one  honest  client. 

We  assume  that  each  anytrust  server  is  run  by  a  respected,  reliable,  and  independently 
managed  organization,  each  responsible  for  ensuring  that  its  server  remains  online  and 
uncompromised.  We  envision  these  anytrust  servers  being  deployed  by  a  federation  of  orga¬ 
nizations  wishing  to  support  responsible  forms  of  anonymous  participation:  e.g.,  providers 
of  online  services  such  as  Wikipedia  or  Twitter,  anonymity  system  providers  such  as  the 
Tor  project,  non-profit  organizations  whose  aim  is  to  further  online  privacy  and  anonymity, 
or  even  for-profit  organization  desiring  strong  guarantees  and  large  anonymity  sets  for  their 
clients. 

In  such  a  deployment  scenario,  we  expect  the  servers  to  offer  high  reliability  and  to  offer 
clients  with  a  high  level  of  confidence  that  at  least  one  honest  server  exists.  In  practice,  we 
hope  and  expect  a  majority  of  the  servers  to  be  honest,  allowing  for  an  efficient  resolution 
of  issues  related  to  the  servers’  performance  or  availability,  should  they  arise,  but  we  leave 
such  availability  issues  outside  the  scope  of  this  paper. 
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2.2  Protocol  Overview 


The  main  idea  underlying  DAGA  is  to  allow  a  client  to  authenticate  anonymously,  and 
at  the  same  time  enforce  proportionality,  by  enabling  the  servers  to  link  authentications 
of  the  same  client.  To  achieve  this  goal,  we  use  a  combination  of  proofs  of  knowledge  to 
prove  membership  to  a  particular  group  and  per-client  linkage  tags  that  effectively  become 
clients’  anonymous  IDs. 

Each  client  i  authenticates  using  a  publicly  available  authentication  context  C,  which 
consists  of  a  group  definition  G  and  other  per-round  authentication  information.  A  client 
i  prepares  and  sends  his  authentication  message  to  an  arbitrarily  chosen  server  who  starts 
the  collective  process  of  producing  the  client’s  final  linkage  tag  by  all  servers,  and  upon  its 
completions  responds  to  the  client  with  an  authentication  decision  as  shown  in  Figure  [l] 

To  produce  an  authentication  message,  a  client  i  generates  an  initial  linkage  tag  Tg  = 
h}  k~1  ,  where  hi  is  the  client’s  per-round  generator  assigned  by  the  servers  and  s &  is  a 

shared  secret  for  every  server  k  that  a  client  generates  in  a  way  that  each  server  is  able 
to  independently  reconstruct  it.  In  addition  to  creating  the  tag,  the  client  proves  in  zero- 
knowledge  that  he  correctly  computed  Tg  and  that  he  is  a  member  of  the  group  G  and 
therefore  he  knows  a  private  key  Xi  that  corresponds  to  one  of  the  public  keys  included  in 
the  group  definition.  A  client  i  executes  the  following  interactive  “OR”  proof  |14j|21  : 

PK  =  {v?=1(I  know  private  key  Xi  a  T0  is  correctly  based  on  hi)} 


After  completing  these  steps,  client  i  securely  erases  his  private  ephemeral  state  and  sends 
to  some  server  j  his  tag,  proof,  and  all  other  information  needed  by  the  servers  to  process 
his  authentication  request.  The  server  who  receives  i’s  authentication  request,  verifies  the 
attached  proof,  and  processes  the  initial  tag  by  scrubbing  from  T0  the  secret  Sj  it  shares 
with  i  and  adding  his  own  per-round  secret  r? .  Finally,  server  j  proves  in  zero-knowledge 
that  he  correctly  performed  these  steps  and  generates  the  following  proof  using  a  standard 


proof  of  knowledge  about  discrete  logarithms  19,29,53 


PK  =  {(Tag  Tj  is  correct  a  I  know  my  secret  a,)} 


The  remaining  servers  repeat  this  process,  however,  also  verifying  that  the  proof  coming 

from  the  previous  server  is  valid.  Provided  that  the  client  i  and  the  servers  correctly  follow 

Flm-  r* 

the  protocol,  it  yields  a  final  linkage  tag  Tj  =  h)  k~1  ' .  Each  final  linkage  tag  is  unique 
to  a  client  and  remains  the  same  for  each  authentication  within  the  same  context  C  as  the 
tag  depends  on  a  client’s  generator  and  a  product  of  all  servers’  secrets  which  remain  the 
same. 


2.3  Security  Properties 

DAGA  provides  for  a  deniable  and  anonymous  authentication  scheme  that  maintains  its 
properties  even  if  a  client’s  private  key  is  compromised.  A  client  should  be  able  to  convince 
the  servers  that  he  is  a  unique  member  of  a  particular  group,  without  disclosing  his  non- 
anonymous  identity  and  without  leaving  any  evidence  that  can  be  used  later  on  to  link  him 
to  his  well  known  identity.  Anonymity  and  deniability  should  persist  even  in  the  case  of  a 
compromise  of  a  client’s  private  key  after  the  round  completion.  More  specifically,  DAGA 
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Figure  1:  Conceptual  model  of  DAG  A 


maintains  anonymity  and  deniability  as  long  as  the  private  keys  of  at  least  two  honest 
members  and  a  private  key  of  at  least  one  honest  server  are  not  compromised.  To  maintain 
forward  security,  the  basic  DAGA  protocol  assumes  that  at  least  one  honest  server’s  pri¬ 
vate  key  remains  secure.  Section  5.4  proposes  an  extension  that  relaxes  this  requirement, 
however,  preserving  forward  secrecy  even  if  all  servers  are  eventually  compromised. 

In  addition  to  completeness  and  soundness ,  DAGA  offers  four  security  properties:  anonymity , 
deniability ,  forward  anonymity ,  and  proportionality. 

Soundness:  Under  the  Discrete  Logarithm  assumption,  servers  only  accept  authentica¬ 
tion  requests  coming  from  a  client  who  is  a  member  of  a  group  G  specified  in  his  authenti¬ 
cation  context. 

Anonymity:  Informally  speaking,  we  want  to  ensure  that  after  a  complete  protocol  run, 
an  adversary  cannot  guess  which  group  member  has  been  authenticated  with  a  probability 
greater  than  random  guessing.  DAGA  provides  anonymity  under  the  DDH  assumption  in 
the  random  oracle  model. 

Forward  Anonymity:  We  extend  the  anonymity  property  to  situations  in  which  an 
adversary  obtains  a  client’s  private  key  but  only  after  a  protocol  run  has  completed,  and 
ensure  that  the  knowledge  of  even  all  but  the  honest  server’s  key  does  allow  an  adversary 
to  break  any  client’s  anonymity. 

Deniability:  We  want  to  ensure  that  the  protocol  does  not  leave  a  “paper  trail”  that 
an  adversary  could  use  to  link  a  client  to  his  authentication  requests  based  on  intercepted 
authentication  transcripts.  This  guarantee  persists  even  in  the  case  of  a  compromise  of 
private  keys  yielding  an  interesting  notion  of  forward  deniability. 

Proportionality:  We  enforce  that  a  client  can  authenticate  as  a  unique  member  only 
once  given  a  particular  authentication  context  and  each  subsequent  authentication  request 
within  the  same  context  is  recognized  as  coming  from  that  client.  At  the  same  time,  we 
ensure  that  client’s  authentications  made  within  two  different  authentication  contexts  are 
unlinkable.  Additionally,  proportionality  persists  even  when  new  clients  are  added  to  a 
group  because  proportionality  is  independent  of  the  group  membership. 


3  Applications 

DAGA  may  be  useful  in  many  applications  desiring  anonymous  authentication,  such  as 
online  surveys,  electronic  coupons,  trial  subscriptions,  etc.  DAGA  is  most  suitable  for 
authentication  into  well-defined,  closed  groups  of  manageable  size,  and  when  guarantees  of 
deniability  and  forward  security  are  needed. 
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3.1  Distributing  Keys  for  Group  Anonymity  Systems 

Most  anonymity  systems  fall  into  two  categories:  mix  networks  15)  (mix-nets)  mask  the 
identity  of  the  sender  by  forwarding  messages  through  multiple  relays,  and  Dining  Cryp¬ 
tographers  networks  [IT]  (DC-nets)  leverage  secrets  exchanged  within  a  well-defined  group 
of  members  to  anonymize  messages.  While  mix-nets  based  systems  (e.g.,  Tor  [24| )  are 
efficient,  they  do  not  provide  unconditional  anonymity  and  traffic  analysis  resistance  as 
DC-nets  based  systems  (e.g.,  Dissent  [?,|61  ,  Herbivore  [54))  do. 

To  provide  accountability  -  the  ability  to  identify  and  expel  members  that  attempt  to 
disrupt  group  communication  -  Dissent  requires  each  member  to  have  a  long-term  signing 
key.  This  key,  if  well-known,  links  the  intermediate  output  of  the  protocol  to  the  key’s 
owner,  and  links  the  protocol’s  entire  output  to  a  particular  group  of  keys.  If  a  client’s 
identity  is  defined  by  a  long-term  non-anonymous  key  pair,  a  compromise  of  the  client’s 
private  key  could  retroactively  compromise  the  user’s  anonymity  in  all  past  exchanges. 

Therefore,  an  anonymity  system  such  as  Dissent  can  leverage  DAGA  to  set  up  ephemeral 
pseudonyms  (signing  keys)  for  participating  group  members,  breaking  the  link  between  the 
client’s  long-term  key  (and  identity)  and  the  anonymous  exchanges,  while  ensuring  fairness 
via  DAGA’s  proportionality  property.  Additionally,  we  can  achieve  a  larger  anonymity 
set  and  plausible  deniability  for  the  anonymous  communication  if  we  draw  ephemeral 
pseudonyms  from  a  much  larger  group  of  members  than  those  who  actively  participate: 
e.g.,  many  “members”  may  be  conscripted  into  the  group  without  their  participation  or 
knowledge. 

3.2  Anonymous  Voting  with  Deniability 

DAGA  may  lend  itself  to  certain  forms  of  anonymous  voting.  Anonymity  (to  preserve 
voter’s  privacy)  and  proportionality  (to  enforce  one-voter  one-vote  rule)  is  generally  re¬ 
quired  in  any  anonymous  voting  scheme.  Many  anonymous  e- voting  schemes  |2, 38, 39, 42 
provide  additional  properties  such  as  coercion-resistant  and  receipt-freeness,  which  offer  a 
weaker  notion  of  deniability.  DAGA’s  deniability  property  ensures  that  once  an  election 
has  ended,  the  resulting  communication  transcript  leaves  no  verifiable  proof  that  the  vote 
even  occurred.  DAGA  may  thus  be  attractive  for  voting  in  a  “dissident  forum”  under 
repression  from  an  authoritarian  regime,  for  example. 


3.3  Secure  Access  to  Sensitive  Resources 


We  can  envision  using  DAGA  to  distribute  access  tokens  to  resources,  in  particular  to 
sensitive  resources,  in  a  way  that  gives  access  to  a  certain  group  of  clients  while  providing 
deniability  of  ever  requesting  those  sensitive  resources. 

Additionally,  because  DAGA  provides  proportionality,  the  servers  can  keep  track  of 
requests  made  by  a  particular  anonymous  user  based  on  his  final  linkage  tag.  This  gives 
the  servers  the  ability  to  limit  access  to  resources  as  desired  (to  one  or  k  times)  without 
exposing  a  client  who  inadvertently  makes  k  + 1  requests  as  done  in  many  fc-show  credential 


systems  1 41 
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3.4  Server-provided  Signatures 


After  a  client  has  been  successfully  authenticated  as  a  unique  group  member,  he  might 
request  that  the  servers  collectively  perform  a  specific  action  on  his  behalf,  for  example  to 
sign  a  message  anonymously  and  deniably. 

This  might  be  accomplished  in  several  ways.  Servers  might  sequentially  sign  a  message 
as  they  process  the  client’s  tag  provided  that  the  client’s  proof  is  valid.  At  the  end  of 
a  successful  authentication,  the  servers  might  endorse  a  collective  ephemeral  signing  key 
and  produce  a  signature  on  the  provided  message.  Alternatively,  a  client-defined  subset  of 
servers  might  issue  a  threshold  DSS  signature  1 30  31  . 


3.5  Supporting  Anonymous  Federated  Login 


Crypto-Book  |46|  provides  for  a  privacy-preserving  and  accountable  digital  identities.  It 
leverages  the  existing  digital  identity  providers,  such  as  Facebook  or  Twitter,  and  the  use 


of  public- key  encryption  and  linkable  ring  signatures.  Linkable  ring  signatures  44,45  allow 


a  group  member  to  anonymously  sign  a  message  in  a  way  that  hides  his  identity  but  allows 
others  to  verify  that  the  signature  was  produced  by  a  group  member  and  to  link  all  future 
signatures  as  coming  from  the  same,  anonymous  member. 

DAGA  can  be  used  in  place  of  any  linkable  ring  signature  scheme  as  it  provides  the  same 
functionality  (anonymity  and  linkability)  while  adding  deniability  and  forward  security. 


4  Protocol  Description 

4.1  Notation 

We  denote  the  client  z’s  proof  of  correctness  as  PK'*'eni,: ,  the  server  j’s  proof  of  correctness 
as  Y>¥^rverj ,  and  the  server  j’s  proof  of  a  client  i’s  misbehavior  as  PK2  j(t'1 .  We  denote 
the  client  i’s  initial  linkage  tag  as  Tq,  the  intermediate  linkage  tag  created  by  a  server  j  as 
Tj,  and  the  client  i’s  final  tag  as  Tj.  We  will  omit  the  client’s  ID  from  Tq  (Tj)  and  write  T0 
(T^-)  when  it  is  clear  from  the  context  which  client  the  tag  belongs  to.  We  denote  a  client 
i’s  authentication  message  as  Mq  and  a  server’s  j  message  as  M  •. 

To  simplify  notation,  we  will  omit  “mod  p”  when  performing  computation  on  elements 
of  Zp  and  “mod  q”  when  performing  computation  on  exponents.  We  will  denote  choosing 
a  random  element  x  from  Z*  as  x  £r  Z* 

q  y 


4.2  Building  Blocks 
E-Protocols 


Zero- knowledge  proofs  of  knowledge  1 32 1  are  proofs  that  yield  nothing  beyond  of  the  validity 
of  the  assertion  a  prover  P  wants  to  convince  a  verifier  V  about.  However,  such  proofs 
normally  require  a  large  number  of  interactions  between  the  prover  and  verifier.  A  E- 
protocol  22  is  a  special  type  of  an  interactive  zero-knowledge  proof  of  knowledge  that 


requires  only  one  interaction  and  always  consists  of  exactly  three  moves:  given  common 
input  I  (1)  P  sends  a  commitment  t  to  V,  (2)  V  responds  with  a  random  Gbit  challenge  c, 
and  (3)  P  sends  back  a  response  r.  V  makes  a  decision  based  on  (I,  t,  c,  r).  By  definition  22 
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a  E-protocol  has  the  properties  of  completeness,  special  soundness  and  special  honest- 
verifier  zero-knowledge.  The  client’s  and  servers’  proofs  instantiated  in  DAG  A  have  these 
properties. 


‘OR”  Proofs 


An  “OR”  proof  of  knowledge  is  an  example  of  a  E-protocol  and  allows  a  prover  to  convince 
a  verifier  that  he  knows  a  secret  x  that  corresponds  to  one  out  of  two  assertions  without 
the  verifier  learning  which  one.  An  “OR”  proof  can  be  easily  generalized  to  proving  the 
knowledge  of  a  witness  to  one  of  many  assertions  (“1-out-of-n”)  or  even  multiple  witnesses 
( “fc-out-of-n” ) . 

DAGA  makes  use  of  interactive  and  non-interactive  proofs.  The  client’s  proof  is  an  in¬ 


teractive  protocol  instantiated  using  the  techniques  of  Camenisch  and  Stadler  14  which  are 


an  extension  of  the  previous  works  on  proof  of  knowledge  [21 ,291,53  .  The  server’s  proofs  uses 
non-interactive  protocols  based  on  Schnorr’s  proof  of  knowledge  of  discrete  logarithms  53  , 
proof  of  equality  of  discrete  logarithms  [l9j,  While  E-protocols  are  interactive  by  nature,  a 
heuristic  proposed  in  [29 1  allows  to  replace  the  interaction  with  a  verifier  with  a  hash  func¬ 
tion  modeled  as  a  random  oracle.  For  simplicity,  we  write  “proof’  or  “proof  of  knowledge” 
for  “three-move  honest-verifier  computationally  zero-knowledge  proof  of  knowledge” . 


4.3  Assumptions 

We  assume  that  communication  channels  exist  between  all  parties  and  a  client  has  an 
authenticated  channel  with  every  server.  We  assume  an  adversary  that  is  polynomial-time 
limited,  can  control  a  colluding  subset  of  up  to  n  —  2  clients  and  up  to  m  —  1  servers,  and 
can  observe  and  record  all  network  messages. 

We  assume  that  each  client  has  a  long-lived  non-anonymous  identity  associated  with  a 
public-private  key  pair.  We  define  a  client’s  identity  as  his  associated  key  pair;  therefore,  a 
client  i  represents  a  client  who  owns  a  public  key  X%.  Specifically,  each  client  i  has  a  long¬ 
term  Diffie-Hellman  (DH)  key  pair  consisting  of  a  private  key  x,;  and  public  key  A,;  =  gXi 
and  each  server  j  has  a  corresponding  private/public  key  pair  ( yj,Yj  =  gyj).  We  assume 
that  there  is  a  readily  available  group  definition  G  =  (A,  Y )  listing  clients  and  servers  and 
their  long-term  public  keys,  Xt  and  Yj  respectively.  The  author  of  a  group  definition  may 
conscript  arbitrary  clients  knowing  only  their  public  keys.  Some  of  the  clients  listed  in 
the  group  definition  need  not  ever  participate  in  the  protocol  or  even  be  aware  that  they 
are  included.  The  group  definition  is  a  part  of  an  authentication  context  which  defines  all 
constants  for  each  authentication  round. 


4.4  Authentication  Context 

In  DAGA,  a  client  i  anonymously  authenticates  as  a  member  of  a  particular  group  G  with 
the  help  of  a  set  of  anytrust  servers  using  a  publicly  available  authentication  context  C .  An 
authentication  context  C  =  (G,  R,  H,p,  g)  consists  of  a  group  definition  G,  a  set  R  of  each 
server’s  commitment  to  a  per-round  secret,  a  set  H  of  each  client’s  per-round  generators,  a 
safe  prime  p  =  2q  +  1  where  q  is  a  sufficiently  large  prime,  and  a  generator  g  of  the  order  q 
subgroup  Q  of  Z*.  We  define  a  group  G  as  a  tuple  (A',  4')  where  A  is  a  set  of  the  n  clients’ 


public  keys  and  Y  is  a  set  of  the  m  servers’  public  keys.  To  generate  R  =  (R\, . . . ,  Rm),  each 
server  chooses  a  secret  rj  Er  Z*  and  publishes  a  commitment  Rj  =  grj .  H  =  (hi, . . . ,  hn) 
consists  of  n  unique  per-round  generators  of  Q,  one  for  each  client  i,  such  that  no  one  knows 
the  logarithmic  relationship  between  any  hi  and  g  or  between  hi  and  h#  for  any  pair  of 
clients  i  A  i' ■  Section  6.5  describes  how  to  find  these  generators  and  Section  6.3  further 
discusses  issues  related  to  creating  and  using  an  authentication  context. 


4.5  Client’s  Protocol 

A  client  i  wishing  to  authenticate,  obtains  an  authentication  context  C,  uses  it  to  produce 
an  authentication  message  M°,  and  sends  it  to  one  arbitrarily  chosen  server  listed  in  Y. 
Upon  receiving  the  client’s  message,  all  servers  collectively  process  and  either  accept  or 
reject  i’s  authentication  request.  If  V s  request  is  accepted,  then  it  results  in  a  final  linkage 
tag  Tj.  It  it  is  rejected,  however,  then  the  client’s  proof  PKci,ent'  is  invalid,  at  least  one 
server  produces  a  proof  Y>YS2rLerj<''')  of  the  client’s  misbehavior,  or  some  server  produces  an 
invalid  proof  PK^f  "’e?\ 

We  define  an  authentication  round  with  respect  to  a  particular  authentication  context 
C.  Each  authentication  request,  regardless  of  the  identity  of  the  originating  client,  belongs 
to  the  same  round  if  it  is  made  with  respect  to  C .  All  requests  within  the  same  round  are 
linkable,  that  is,  each  time  a  client  i  authenticates,  the  servers  will  be  able  to  link  these 
requests  as  coming  from  some  client  from  G. 

A  client  i  performs  the  following  steps  to  create  M°. 


Step  1  :  Client  i  first  picks  an  ephemeral  private  DH  key  Zi  Er  Z*  and  computes  a 
public  key  Z%  =  gZi .  Client  i  keeps  Zi  secret. 

Step  2  :  For  each  server  j,  i  computes  a  shared  secret  exponent  Sj  =  TiiiY*1)  = 
Hi (gVjZi),  where  R\  :  {0, 1}*  — *  Z*  is  a  hash  function  and  Yj  is  the  sever  j’s  public  key  as 


listed  in  Y. 

nz*_  sk 

Step  3:  Client  i  computes  his  initial  linkage  tag  Tg  =  h\  k~x  using  his  per-round 
generator  hi  as  listed  in  H  and  the  secret  exponents  shared  with  all  servers.  Then,  for  each 
server  1  <  j  <  m,  *  computes  S  =  (So, . . .  ,Sm),  a  set  of  commitments  to  a  secret  Sj  he 
shares  with  each  server  j:  Sj  =  gkE=i  sk  such  that  Sq  =  g,  Si  =  gsi ,  ,  Sm  =  grL=isfc. 

Finally,  client  i  sets  S  =  (Zi,S). 

Step  4:  Now,  client  i  proves  that  (i)  he  correctly  followed  the  protocol,  that  is  his 
initial  linkage  tag  Tg  is  correctly  constructed  using  h,  and  s  =  Y\k=i  anc^  (™)  belongs 
to  the  group  G  because  he  knows  some  private  key  x  that  corresponds  to  some  public  key 
X  e  X.  To  do  so,  i  runs  an  interactive  proof  of  knowledge  as  described  in  Section 
client’s  proof  PKchentl  looks  as  follows. 


4.7 


The 


PK{(Xi,s)  :  {vL i(Xk  =  gXk  a  Sm  =  gs  a  T0  =  h%)} 

Step  5  :  Client  i  securely  erases  each  secret  Sj  and  Zj.  Finally,  client  i  creates  and  sends 
to  an  arbitrarily  chosen  server  j  his  message  =  (C,  S,Tq,  Pq),  where  C  =  (G,R,H,p,g) 
is  the  authentication  context  i  used,  S  =  (Zi,  So, ... ,  Sm)  is  the  client’s  ephemeral  public 
key  and  the  set  of  client’s  commitments,  Tg  is  the  initial  linkage  tag,  Pq  is  the  client’s  proof. 
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4.6  Servers’  Protocol 

All  servers  collectively  process  a  client  V s  authentication  message  M  ■*  and  at  the  end  of  this 
process  either  reject  V s  authentication  request  or  accepts  it  as  output  V s  final  linkage  tag 
Tj.  A  client  i  arbitrarily  chooses  some  server  j  to  whom  he  sends  M-1.  We  denote  that 
server  j  as  server  1,  since  j  is  the  first  server  to  process  i’s  request,  and  denote  server  2  as 
j  +  1  and  finally  the  last  server  m  as  j  —  1.  This  defines  a  unique  order  based  on  the  list  of 
server  in  Y  in  which  each  server  processes  V s  message. 

The  first  server  to  process  the  client’s  authentication  requests  receives  the  message 

=  (C,  S,  Tq,Pq).  Then,  each  server  j  creates  a  message  Mj  =  Pj)  to  pass  to 

the  next  server  in  sequence,  where  Mj- 1  is  the  authentication  message  M-1  (if  j  =  1)  and 
the  message  received  from  the  previous  server  (if  j  >  1),  T-  is  the  linkage  tag  produced  by  j 
and  Pj  is  the  proof  produced  by  j.  Each  Mj  for  j  >  1  consists  of  all  previous  messages  such 
that  each  server  j  can  verify  all  messages  produced  thus  far  (including  the  client’s  original 
message  M-1). 


Each  server  j  performs  the  followings  steps  to  create  Mj. 


Step  1  :  Server  j  checks  the  incoming  message  Mj_r  and  rejects  it  the  message  is  valid. 
Then,  j  checks  the  proof  of  correctness  of  the  previous  servers’  computations  (unless  j  =  1) 
as  well  as  the  client’s  proof  Pq.  Server  j  proceeds  only  if  all  proofs  are  valid,  and  aborts 
otherwise. 

Step  2  :  First,  server  j  reconstructs  the  secret  Sj  he  shares  with  the  client  as  Sj  = 
' Hi(Zy i)  =  'Hi{gyiZ).  Then,  j  verifies  the  client’s  commitments  <Sj_i  and  Sj  against  Sj. 
That  is,  the  server  checks  that  Sj  =  S'^_ l .  If  yes,  then  j  proceeds  to  Step  3  and  if  not, 
then  j  reveals  Sj  together  with  a  proof  that  he  computed  it  correctly  based  on  the  client’s 
commitment  Z  and  his  public  key  Yj  as  described  in  Section  4.9  In  such  a  case,  server  j 
produces  the  following  proof  pK2eri;er. 


PK{{yj)  :  (Zs.  =  ZVi  a  Yj  = 


Server  j  creates  and  sends  to  the  next  server  his  message  Mj  =  Mj_ i,  Tj  =  0,  Pj  =  PYf^rver . 

Step  3  :  Server  j  computes  his  intermediate  linkage  tag  T-  =  (T^j  using  his 

per-round  secret  rj  and  a  multiplicative  inverse  of  the  shared  secret  Sj  which  results  in  a 


ni.irfcrGLi+i*fc 


tag  Tj  =  h% 
described  in  Section 


4.8 


Now,  j  produces  a  non-interactive  proof  Pj  of  correctness  as 
The  server  proves  that  he  correctly  computed  the  new  tag  T- 


with  respect  to  the  server’s  per-round  commitment  Rj 
produces  PKfr,jer  as  follows. 


and  the  shared  secret  Sj.  Server  j 


PK{(rj ,  Sj)  :  7/  ,  =  7/  a  Rj  =  a  Sj  =  Sy  , } 

Step  4:  Finally,  server  j  securely  erases  Sj,  forms  his  outgoing  message  Mj  =  (Mj_iTj,  Pj 
pRserner),  an(^  sen(^s  server  j  +  1  if  j  <  m,  or  to  all  servers  if  j  =  m. 

Step  5  :  Server  j  securely  erases  his  per-round  secrets  rj  upon  a  completion  of  a  round, 
that  is  when  the  authentication  context  C  expires. 
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After  a  successful  completion  of  the  protocol,  all  servers  learn  a  final  linkage  tag  T,  = 

nm-  rk  J 

hPk~1  _  The  ^ag  only  depends  on  the  client’s  per  round  generator  hi  and  a  product  of 
all  servers’  per-round  secrets  rj,  regardless  of  the  initial  linkage  tag  T0.  Thus,  a  client  can 
obtain  only  one  linkage  rage  per  round. 

4.7  Client’s  Proof  PKclienti 

Each  clients  i’s  authentication  message  M?  includes  the  following  proof  of  knowledge  Po : 

PK{(Xi,s)  :  {v%=1(Xk  =  gXk  a  Sm  =  gs  a  T0  =  h%)} 

In  this  proof,  the  client  i  proves  that  he  either  knows  a  private  key  x±  and  his  tag  T0 
is  correct,  or  that  he  knows  X2  and  T0  is  correct,  including  an  “OR”  statement  for  each 
private  key  included  in  X.  Because  i  knows  only  one  private  key,  namely  x%,  he  simulates 
the  “OR”  statements  for  all  other  private  keys  in  a  way  that  will  convince  the  servers 
that  the  authenticating  client  knows  one  private  key  and  the  tag  is  properly  formed.  More 
specifically,  client  i  proves  that  that  (i)  client  ?’s  linkage  tag  To  is  created  with  respect  to 
his  per-round  generator  hi,  (ii)  Sm  is  a  proper  commitment  to  s  =  rifcli  sfc>  the  product  of 
all  secrets  that  i  shares  with  the  servers,  and  (in)  client  i's  private  key  x%  corresponds  to 
one  of  the  public  keys  included  in  the  group  definition  G. 


Prover’s  Steps  The  prover,  a  client  i  holding  private  key  x%  and  s  performs  the  following 
step  to  calculate  Pq  =  P: 


1.  Choose  wi, . . . ,  wn  such  that  wi  =  0  and  Wi  Sr  Z*  for  i  A  i,  and  choose  ui.o,  ui.i, . . . ,  vn.o,  vn,i  Br 
Z*.  For  each  client  i  e  G,  compute  commitments  U.o  =  X™lgVi  0,  ti.  io  =  S^gViA,  and 

,  _  rpWi  1»i.l 

ti- 11  -  10  hi  ■ 

Set  t  =  (ti.o,  ti.ioi  ii.n,  •  •  • ,  tn.oTn.ioTn.il)  and  send  it  to  an  arbitrarily  chosen  server. 


2.  Upon  receiving  the  client’s  commitments,  the  severs  collectively  generate  a  random 
challenge  cs  (as  described  in  Section  6.4)  and  send  cs  back  to  the  client. 


3.  Compute  c  =  (ci, . . . ,  cn)  as: 


°s  —  Zjfc=l  wk 
Wi 


for  i  =  i 
otherwise 


Compute  responses  r  =  (ri.o,  ri.i, . . .  ,^.0,^.1)  as  follows.  Let  Xj.o  =  x%.\  =  0  for  all 
i  /  i.  let  Xj.o  =  Xi,  and  let  xyi  =  s.  Compute  r,.fc  =  —  CiXi±  for  all  1  ^  ^  n  and 

k  B  {0, 1}.  Set  P  =  ( cs,t ,  c,  r). 


Verifier’s  Steps  The  verifier,  one  of  the  servers,  performs  the  following  steps  to  verify 
the  proof. 


1.  Check  the  commitments  ti.o 
1  <  i  <  n. 


Xf 


rXi.  0 


Cj.10 


=  sc 


gri  l,  and  U.u  =  T()'  h(l  i  ,  for  all 


2.  Check  the  challenge  cs  =  <H- 
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4.8  Server’s  Proof:  Proving  Correctness  of  its  Work 

After  processing  an  incoming  tag  T^_1,  each  server  j  must  prove  the  correctness  of  its 
computations.  That  is,  a  server  produces  a  proof  of  knowledge  PK*e?  terj  that  he  created 
the  tag  Tj  according  to  the  protocol  specification.  That  is,  j  proves  that  he  (i)  correctly 
recovered  the  shared  secret  Sj ,  (ii)  used  the  correct  per-round  secret  rj  with  respect  to 
Rj  £  R ,  and  (in)  correctly  removed  Sj  and  added  rj  to  the  tag. 

PK{(rj}sj)  :  ,  =  7/  a  Rj  =  gr *  a  Sj  =  S/  , } 

Server  j  can  generate  such  a  proof  if  it  knows  rj  and  sj .  Each  honest  server  knows  its  own 
per-round  secret  rj,  and  the  secret  Sj  that  relates  Sj  to  Sj- 1,  otherwise  if  j  were  unable 
to  reconstruct  a  correct  Sj,  then  he  would  have  exposed  the  client  by  producing  a  proof 
pK^eruerj  an(j  woujfj  }iave  never  produced  his  tag  T-. 

Prover’s  Steps  The  prover,  server  j  holding  Sj  and  rj,  performs  the  following  steps  to 
create  Pj  =  P. 

1.  Choose  v\,V2  £r  Z*.  Calculate  t\  =  Tj^_ j T~V2 ,  t-2  =  gVl,ts  =  S'J7 , . 

2.  Calculate  c  =  'H.2{Tj-\,  Tj,  Rj,  g,  Sj,  Sj-\,t\,t2,  t:i),  where  R2  ■  {0, 1}*  — >•  Zp  is  a  hash 
function. 

3.  Calculate  r\  =  v\  —  crj  and  r2  =  V2  —  csj. 

4.  Set  P  =  (ti,t2,h,c,ri,r2). 

Verifier’s  Step  The  verifier,  another  server,  upon  receiving  Pj  can  verify  the  proof  as 
follows. 

1.  Reconstruct  commitments  t\  =  Tj^_ t T~r'2 ,  t'2  =  griRj,t'3  =  Sr-2_]S‘j. 

2.  Check  c  =  ^(Tj-i,  Tj,  Rj,  g,  Sj,  Sj-i,  t[,  t'2,  t'3). 

4.9  Server’s  Proof:  Exposing  a  misbehaving  client 

To  create  a  tag  T-,  server  j  needs  to  reconstruct  and  then  remove  the  secret  Sj  it  shares  with 
the  client  from  the  incoming  tag  Tj_  1.  Server  j  calculates  Sj  =  77 1  ( Zy:> )  using  the  client’s 
commitment  Z  and  its  own  private  key  t/j,  and  verifies  that  the  recovered  secret  is  correct 
by  checking  Sj  =  Sj i1.  If  the  recovered  secret  is  not  correct,  then  j  exposed  the  client  as 
dishonest  by  providing  a  proof  to  other  servers.  To  do  so,  the  server  reveals  the 

secret  Sj  it  computed  and  ZSj  =  Zyi ,  the  preimage  of  Sj  under  77 1.  Then,  server  j  prepares 
a  proof  that  he  (i)  used  his  private  key  yj  that  corresponds  to  a  public  key  Yj  e  Y ,  and  (ii) 
correctly  computed  ZSj  by  raising  the  client’s  commitment  Z  to  his  private  key  yj.  Server 
j  prepares  the  following  proof  of  knowledge: 

PK{(yj)  :  (Za.  =  Zyr  A  Yj  =  g*)}. 

After  receiving  and  verifying  PK.f^rverj ,  each  server  can  can  reconstruct  Sj  =  77 1  {ZSj),  check 
that  indeed  Sj  ¥=  S*:I_  { ,  and 
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Prover’s  Steps  The  prover,  server  j  holding  a  private  key  yj,  performs  the  following 
steps  and  obtains  Pj  =  ( Zs. ,  P) : 

1.  Choose  v  £r  Z*.  Calculate  t\  =  Zv  and  t2  =  gv. 

2.  Calculate  c  =  'H2(ZSj ,  Z,  Yj,  g,  t\,  t?). 

3.  Calculate  r  =  v  —  cyj 

4.  Set  P  =  (h,t2,c,r). 

Verifier’s  Steps  The  verifier,  either  a  server  or  the  client,  upon  receiving  Pj  can  verify 
the  proof  as  follows: 

1.  Reconstruct  commitments  t\  =  Zr  Zcs_  and  t2  =  9rYf- 

2.  Check  c  =  T-L2 {ZSj  ,Z,Yj,g,  t\ ,  t'2). 

5  Extensions  of  DAGA 

In  this  section  we  describe  several  possible  extensions  of  our  main  protocol.  First,  we  discuss 
ideas  for  improving  DAGA’s  performance,  then  we  discuss  trading  deniability  for  verifiabil¬ 
ity,  show  how  to  give  the  servers  the  ability  to  collectively  revoke  a  client’s  anonymity,  show 
how  to  make  DAGA  secure  on  full  clients’  and  servers’  key  exposure,  and  lastly  we  present 
a  variant  of  DAGA  in  which  the  client  has  a  chance  to  inspect  his  linkage  tag  before  it  is 
revealed  to  the  servers. 


5.1  Improving  Efficiency 


Currently,  the  computation  and  communication  overhead  of  DAGA  grows  linearly  in  the 
number  of  members  in  a  group  G.  Ideally,  we  would  like  to  improve  the  efficiency  from 
0(n)  to  0(1)  to  make  it  independent  from  the  group  size  n. 

One  possibility  is  to  use  a  cryptographic  accumulator  1 28]  (or  a  dynamic  accumulator  1 1 
to  retain  support  for  evolving  groups)  that  makes  it  possible  to  accumulate  multiple  values 
into  a  single  one  such  that  for  each  accumulated  value  there  is  a  proof  that  the  value  was 
correctly  incorporated.  Therefore,  instead  of  using  a  1-out-of-n  “OR”  proof,  we  could  first 
accumulate  all  public  keys  and  then  prove  that  a  client’s  public  key  is  indeed  a  part  of  the  the 
resulting  short  accumulator.  Similar  ideas  were  used  to  design  a  short  linkage  ring  signature 
scheme  [3|,  for  example.  Another  possibility  is  to  use  more  efficient  proofs  of  knowledge  j  l3i| 


and  new,  efficient  batching  verification  techniques  for  proofs  of  partial  knowledge  36,37  49 
We  fully  expect  to  obtain  a  much  efficient  protocol  using  the  outlined  ideas. 


5.2  Trading  Deniability  for  Verifiability 

DAGA  offers  a  strong  zero-knowledge  notion  of  deniability;  the  protocol  does  not  leave  a 
‘paper  trail”  that  one  could  use  to  prove  that  some ,  and  therefore  at  least  one,  member 
participated  in  the  protocol.  DAGA  achieves  deniability  by  using  an  interactive  rather 
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than  non-interactive  zero- knowledge  proof  on  the  client’s  side.  An  interactive  proof  is 
not  transferable  and  only  “convinces”  the  party  directly  involved  in  the  proof.  In  a  non¬ 
interactive  proof,  the  verifier  is  replaced  with  a  hash  function  |29|  to  create  an  unpredictable 
challenge  that  a  prover  cannot  anticipate  in  advance.  Therefore,  anyone  can  verify  the  non¬ 
interactive  proof,  even  after  the  protocol’s  completion.  This  property,  while  useful,  goes 
against  the  notion  of  deniability  we  set  out  to  achieve.  However,  certain  applications  might 
benefit  from  the  transferability  of  the  proof  that  would  allow  for  a  third-party  verifiability 
that  some  user  or  a  certain  number  of  users  indeed  authenticated. 

Consider  an  anonymous  voting  scenario,  where  voters  want  to  remain  anonymous  but 
wish  for  a  third-party  verifiable  proof  (independently  of  the  election  results)  that  a  specific 
number  of  voters  participated.  A  small  change  to  DAGA,  changing  the  client’s  proof 
from  interactive  to  non-interactive,  easily  achieves  this  goal  and  each  voter’s  authentication 
message  M0  becomes  such  a  proof. 

Interestingly,  trading  deniability  for  verifiability  does  not  affect  other  properties,  specif¬ 
ically  forward  anonymity  and  proportionality.  Moreover,  DAGA  still  retains  a  weaker 
notion  of  plausible  deniability:  since  DAGA  is  anonymous  and  a  group  G  can  be  created 
without  the  listed  members’  participation  or  knowledge,  any  member  can  plausibly  deny 
participating  in  the  protocol. 


5.3  Optional  Anonymity  Revocation 


DAGA  provides  clients  with  a  strong  notion  of  anonymity.  However,  the  ability  to  revoke 
a  client’s  anonymity  might  be  a  desirable  feature  but  only  if  it  is  done  carefully  so  that  the 
client’s  anonymity  is  not  inadvertently  or  maliciously  compromised. 

Any  client’s  anonymity  can  be  revoked  if  each  server  j  reveals  his  per- round  secret  rj .  in 
which  case  the  anonymity  of  all  clients  is  compromised,  or  each  server  reveals  his  secret  Sj 
shared  with  a  client  in  question,  breaking  the  rule  of  retaining  private  input  secret,  however. 
Therefore,  we  wish  for  a  protocol  which  explicitly  allows  for  anonymity  revocation. 

To  achieve  this  goal,  we  use  a  threshold  version  of  the  ElGamal  encryption  scheme 
to  encrypt  the  client’s  ephemeral  private  key  Zi  under  a  public  key  that  is  a  product  of  all 
servers’  commitments  to  their  per-round  secrets  r  (if  we  want  to  limit  anonymity  revocation 
to  the  lifetime  of  an  authentication  context)  or  under  a  public  key  that  is  a  product  of  all 
servers’  long-term  public  keys  (if  we  want  the  ability  to  revoke  clients’  anonymity  at  any 
point). 

After  encrypting  his  ephemeral  key  Zi  under  a  shared  public  key  Kau  of  all  servers, 
a  client  i  produces  a  modified  version  of  the  PKd“f‘  proof  which  includes  a  proof  that 
EKan(zi)  is  an  encryption  of  an  element  committed  to  as  Zi,  using  a  standard  technique 
of  proving  a  property  of  a  ciphertext  from  12  .  To  reveal  a  client’s  identity,  all  servers 


collectively  decrypt  Exall{zi),  retrieve  Zi  and  use  it  to  recover  all  secrets  the  client  shares 
with  the  servers’  finally  recovering  a  per-round  generator,  which  corresponds  to  a  unique 
client  i  as  defined  by  H . 

This  modification  does  not  affect  the  properties  offered  by  DAGA.  Specifically,  the 
anonymity  and  forward  anonymity  properties  are  still  guaranteed,  unless  explicitly  revoked, 
assuming  that  there  is  always  one  honest  and  never  compromised  server. 
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5.4  Secure  on  Full  Key  Exposure 


Currently,  the  forward  anonymity  property  holds  as  long  as  the  honest  server’s  private  key 
is  protected.  If  the  long  term  private  key  Zh  of  the  honest  server  is  known,  an  adversary  who 
controls  all  other  servers  can  recover  the  ephemeral  secret  shared  with  a  client  i  and  calculate 
Sh.  Then,  if  the  adversary  has  access  to  the  previous  authentication  messages  that  include 
the  initial  linkage  tags,  the  adversary  can  trivially  calculate  T0*  =  hf1'"8™  for  every  hi  e  H 
and  compare  with  the  initial  linkage  tags.  Knowing  the  association  of  a  client’s  identity 
with  a  per-round  generator,  the  adversary  breaks  the  anonymity  and  forward  anonymity  of 
every  client  for  whom  he  finds  a  matching  tag. 

We  can  avoid  this  (rather  unlikely  but  not  impossible)  attack  by  adding  a  server-side 
per-round  randomness  into  the  secret  a  client  shares  with  each  server.  This  way  even  if 
the  adversary  compromises  the  server’s  private  key,  the  additional  secret  included  in  Sh  has 
been  forgotten. 

To  do  so,  we  extend  the  authentication  context  C  to  include  an  additional  a  vector 


A  =  A, 


where  A*  = 


g°':i 


as 


and  modify  Step  2  of  the  client’s  protocol  described 
in  Section  4.5  as  follows.  For  each  server  j,  i  uses  both  Aj  and  Yj  to  compute  a  shared 
secret  exponent  Sj  =  'H\(AZ^ ,Yp)  =  T~Li(gajZi,gyjZi).  Then,  each  server  j  recovers  Sj 
Ui{{Zaj ,  zvs )  =  Hi (ga>Zi ,  gy*Zi) . 

The  protocol  works  as  follows. 

1.  Client  i  encrypts  his  ephemeral  key  Z{  under  Rs  =  i\UR  n 


as  follows:  i  chooses 


l  Er  Z*  and  calculates  Ens(zi)  =  (A  =  gr,  B  =  ZiRf 


S) 
client  ■ 


Then,  client  i  creates  a  modified  version  of  the  PKC  !e"*i  proof  appending  to  it  a  proof 
that  ERs(zi)  is  an  encryption  of  an  element  committed  to  as  Zi  using  a  technique  of 
proving  a  property  of  a  ciphertext  from 
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In  order  to  reveal  an  identity  of  a  client,  the  servers  perform  the  following  steps. 

1 .  Each  server  j  calculates  and  publishes  Aj  =  Arj  =  girj  as  well  as  a  proof  of  knowledge 
that  DL(Aj)  =  DL(Rj),  that  is  j  correctly  computed  Aj  by  raising  it  to  its  private 
key  yj. 


2.  All  servers  retrieve  z*  =  B{YYj-\  A™)-1- 

3.  For  each  server  i  e  G,  j  calculates  Sj  =  T~i^(Y)iXZi). 

4.  The  client’s  identity  is  reveled  by  removing  all  secrets  the  client  shares  with  the  servers 
from  a  particular  tag  was  created  to:  (T0)ni=i  si  and  deciding  which  generator  the 
result  is  equal  to. 


PK{(xi,s,Zi )  :  {vl=1(Xk  =  gXk  a  Sm  =  gs  a  T0  =  h%)  a  B  =  zi9^=orj} 

While  we  recognize  that  the  client’s  identity  can  be  revealed  if  each  server  reveals  their 
secret  shared  with  the  client,  we  wish  to  be  able  to  do  so  in  a  way  that  guarantees  that 
a  client  is  aware  of  this  possibility  (by  creating  a  modified  proof  of  knowledge).  This 
modification  does  not  affect  the  properties  offered  by  DAG  A.  Specifically,  the  anonymity 
and  forward  anonymity  properties  are  still  guaranteed  assuming  that  there  is  always  one 
honest  and  never  compromised  server. 
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5.5  Delayed  Revealing  of  Final  Linkage  Tags 

After  a  successful  authentication,  the  severs  immediately  learn  the  client’s  final  linkage  tag. 
However,  the  client  might  want  to  have  an  opportunity  to  “inspect”  the  tag  first  before 
finishing  authentication.  This  way  a  client  could  check  if  the  servers  already  seen  such 
a  tag  by  looking  it  up  in  a  server-published  list  of  the  linkage  tags  seen  in  a  particular 
authentication  context  C  thereby  avoiding  the  potential  risk  of  unintentionally  trying  to 
authenticate  twice  in  a  linkage  context,  for  example. 

This  can  be  easily  accomplished  by  delaying  the  removal  of  the  client-side  secret  s  from 
the  linkage  tag  until  the  client  can  verify  T0  =  hfr.  That  is,  a  client  allows  the  servers 
to  incorporate  their  per-round  secrets  r,  then  verifies  the  resulting  tag,  and  if  the  tag  is 
correct,  he  removes  his  secret  s,  proves  in  zero- knowledge  that  he  did  so  correctly  and  sends 
the  final  tag  back  to  the  servers. 

To  do  so,  a  client  creates  the  initial  linkage  tag  as  before,  T0  =  hf,  however  now  s  is  a 
single  secret  known  by  the  client,  not  a  product  of  all  secrets  i  assigns  to  the  servers,  and  i 
produces  a  proof  PKchenti  as  before. 

Upon  receiving  the  client’s  message  M0,  the  servers  iteratively  incorporate  their  per- 
round  secrets  rj  as  before,  but  this  time  without  removing  the  client’s  secret,  finally  yielding 
a  final  linkage  tag  Ty  =  h*  a .  Each  server  j  prepares  a  simplified  proof  of  its  correctness: 

PK{(rj )  :  Tj  =  Vf  ,  a  Rj  =  gr< 

After  all  servers  process  the  tag,  the  last  server  sends  Tj  and  the  proofs  of  its  correctness  back 
to  the  client,  who  can  verify  the  proofs  and  calculate  the  client’s  final  linkage  Xy  =  {Tj)~s. 
This  way  the  client  has  a  chance  to  inspect  the  tag  before  making  it  available  to  the  servers. 
If  the  client  decides  to  complete  the  authentication,  he  can  prove  the  correctness  of  X y  with 
respect  to  Tj  as  follows 

PK{(s)  :  Tf  =  Tj  a  S  =  gs} 

While  this  approach  gives  the  client  more  control  over  his  authentication  requests,  it 
requires  an  additional  communication  round,  but  might  be  suitable  for  applications  where 
clients  are  limited  to  a  certain  number  of  authentications  within  a  certain  authentication 
context  and  authenticating  more  than  the  allowed  number  of  times  has  negative  conse¬ 
quences. 

6  Practical  Considerations 

6.1  Servers’  Liveness 

DAGA  depends  on  a  set  of  servers  to  process  each  authentication  request.  Therefore,  if 
a  server  goes  offline  or  refuses  to  process  a  message,  the  protocol  stalls  or  aborts.  While 
we  cannot  guarantee  that  DAGA  terminates  if  one  of  the  above  happens,  we  can  employ 
a  wrapper  protocol  that  uses  gossip  techniques  such  as  those  used  in  PeerReview  [35|  to 
ensure  liveness. 


16 


6.2  Dealing  with  Dishonest  Servers 


Before  processing  an  incoming  authentication  message,  each  server  j  verifies  all  proofs  of 
correctness  of  every  server  that  comes  before  j.  If  an  invalid  proof  PK^f”’erfc  or  pp^eri,erfeM 
for  some  server  k  is  discovered,  the  authentication  must  be  aborted  and  the  client  cannot 
be  authenticated.  We  assume  that  the  issue  of  dealing  with  dishonest  servers  within  the 


anytrust  set  is  done  administratively  160,61 


6.3  Authentication  Context 

Generating  an  authentication  context  In  order  to  establish  a  new  authentication 
context,  the  servers  need  to  define  the  clients  who  belong  to  a  group  G  and  establish 
servers’  per-round  secrets  and  clients’  per-round  generators. 

Step  1:  First,  the  servers  choose  a  safe  prime  p  =  2q  +  1  where  q  is  a  sufficiently  large 
prime  a  generator  g  of  a  prime  order  q  group  Q. 

Step  2:  Each  server  j  picks  a  per-round  secret  rj  £r  Z*,  which  is  kept  secret,  and  then 
j  sends  to  other  servers  a  commitment  Rj  =  grj . 

Step  3:  Servers  collectively  establish  a  random  per-round  generator  hi  for  each  client  i 
such  that  no  one  knows  the  logarithmic  relationship  between  hi  and  g ,  or  between  hi  and 
h^  for  any  pair  of  clients  i  /  i' ,  for  example  using  a  technique  described  in  Section  6.5 
Step  4 :  Servers  create  a  set  of  the  servers’  commitments  R  =  (R\, . . . ,  R.rn)  and  clients’ 
generators  H  =  {h\, . . . ,  hn).  Then,  the  servers  publish  an  authentication  context  C  = 
(' G,R,H,p,g ). 


Validity  of  an  authentication  context  An  authentication  context  might  be  one  time, 
where  each  client  is  expected  to  make  exactly  one  authentication  request  or  a  context  may 
remain  valid  for  certain  period  of  time  or  some  maximum  number  of  authentications  made 
by  a  single  clients  or  all  of  clients  in  G.  Since  the  servers  can  keep  track  of  each  anonymous 
client’s  authentication  request,  a  client  may  be  allowed  to  make  up  to  k  requests  so  that 
each  request  beyond  that  is  rejected  regardless  of  the  validity  of  the  supplied  authentication 
message.  After  a  context  expires,  all  servers  securely  erase  their  per-round  secrets  r  making 
it  impossible  to  process  authentication  messages  within  this  context. 

Updating  an  authentication  context  DAGA  supports  the  evolution  of  the  clients  is  a 
particular  group  G  included  a  context  C  in  a  way  that  preserves  the  proportionality  property 
within  that  context.  A  new  client  k  may  be  efficiently  added  to  G,  by  simply  adding  his 
public  key  Xj.  to  X  and  adding  a  new  generator  %  to  H.  The  proportionality  property 
is  preserved,  because  each  client’s  linkage  tag  only  depends  on  the  client’s  generator  and 
the  servers’  per-round  secrets  making  it  independent  of  the  membership  of  G.  After  the 
context  is  updated,  each  client  would  create  P Kc/*ent,;  with  respect  to  the  new  group  G. 
Care  needs  to  be  taken  to  propagate  the  updated  context  to  all  clients  to  avoid  accidentally 
compromising  the  identity  of  the  newly  added  client  as  he  would  be  the  only  one  using  the 
updated  context. 
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6.4  Challenge  Generation 


A  client  i  produces  a  proof  of  knowledge  using  an  interactive  honest-verifier  zero-knowledge 
proof  of  knowledge  as  described  in  Section  47  Because  the  proof  is  interactive,  a  client 
i  must  obtain  a  random  challenge  cs  from  the  servers  after  submitting  his  commitments. 
Additionally,  because  the  proof  is  honest- verifier,  the  challenge  must  be  indeed  randomly 
chosen.  This  can  be  ensured  by  requiring  all  servers  to  collectively  generate  cs  so  that  each 
server,  which  would  include  at  least  one  honest  server,  contributes  its  randomness  towards 


One  approach  to  collectively  establish  cs  is  as  follows. 

Step  1:  Upon  receiving  a  client’s  request,  server  j  assumes  the  role  of  a  leader  and 
requests  that  the  other  servers  generate  a  new  challenge  cs  for  client  i. 

Step  2:  Each  server  i  chooses  c,;  Er  Z*  and  then  calculates  a  commitment  Cj.  Server  i 
signs  and  publishes  Ci. 

Step  3:  Upon  receiving  C%  from  every  other  server  i,  server  j  verifies  if  all  Cj  are  of  valid 
form  and  properly  signed,  and  if  yes  server  j  publishes  an  opening  cj  of  his  commitment  Cj 
and  requests  other  serves  to  open  their  commitments. 

Step  4:  Upon  receiving  an  opening  Cj  from  every  other  server  i,  server  j  verifies  if  every 
Cj  is  indeed  a  valid  opening  of  Cj.  If  yes,  server  j  calculates  cs  =  ci  +  ■  ■  •  +  cm.  Server  j 
collects  all  commitments  Ci,  openings  Cj,  and  the  calculated  challenge  cs  and  forwards  to 
server  j  +  1  who  signs  cs  after  verifying  that  it  was  correctly  calculated. 

Step  5:  Upon  receiving  cs  signed  by  every  other  server,  server  j  forwards  cs  for  the  client 
along  with  a  proof  that  every  other  server  calculated  the  same  value. 

Under  our  assumption,  there  is  at  least  one  honest  server  h  who  will  randomly  choose 
his  Cj  and  therefore  guarantee  that  the  collective  challenge  cs  is  properly  generated. 


6.5  Per-Round  Generators 


For  each  protocol  round,  defined  by  the  same  context  C,  we  require  that  there  is  a  set 
H  =  (hi, . . . ,  hn )  of  n  per-round  generators  of  Q ,  where  there  is  one  unique  generator  hi  for 
each  client  i.  The  proportionality  property  depends  on  the  uniqueness  of  the  final  linkage 
tags.  Each  client  z’s  linkage  tag  Tj  is  unique  and  remains  fixed  within  the  same  C,  precisely 
because  each  client  i  creates  the  initial  tag  T f  with  respect  to  the  same  but  unique  per-round 
generator  hi. 


As  defined  in  Section  4.4,  Q  is  a  multiplicative  cyclic  group  of  prime  order  q.  Therefore, 
all  elements  of  Q,  except  for  the  identity  element,  are  generators  of  Q  so  generating  H 
reduces  to  choosing  n  random  elements  of  Q. 

However,  it  is  important  that  H  is  chosen  randomly  to  ensure  that  the  assumption  no  one 
knows  the  logarithmic  relationship  between  any  hi  and  g  or  between  hi  and  h^  for  any  pair 
of  clients  i  ^  7  holds.  Therefore,  the  anytrust  servers  must  collectively  choose  H  in  a  way 
that  ensures  that  none  of  the  servers  know  the  aforementioned  logarithmic  relationships. 
An  efficient  method  to  hnd  generators  is  to  use  a  hash  function  77  :  {0,1}*  — >  Z*  to  map  a 
per-round  fixed  string  ( i ,  R )  into  each  client  V s  generator. 
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7  Evaluation 


7.1  Implementation 


We  have  implemented  DAGA  within  the  context  of  Dissent  61  using  C++  with  the  Qt 


framework  and  the  CryptoPP  cryptography  library.  The  prototype  implements  both  the 
client  and  server  aspects  of  DAGA,  but  currently  does  not  support  exposing  misbehaving 
clients  nor  any  of  the  extensions  to  DAGA,  discussed  in  Section  4.9  and  Section  [5j  respec¬ 
tively.  The  prototype  assumes  that  all  keys  derive  from  the  same  modulus  and  subgroup, 
and  that  all  participants  have  used  an  outside  channel  to  agree  upon  a  common  set  of 
authentication  servers  and  an  authentication  context.  With  the  introduction  of  DAGA, 
Dissent  now  includes  a  modular  authentication  framework  that  supports  pre-exchanged  keys 
using  Stinson’s  two-way  authentication  protocol  |55]  (Protocol  9.6),  linkable  ring  signatures 
(LRS)  (44 1,  and  DAGA. 


7.2  Micro  benchmarks 

We  evaluate  DAGA  in  comparison  to  pre-exchanged  keys  and  LRS.  The  evaluations  were 
performed  on  a  64-bit  x86  machine  running  Ubuntu  12.04.  This  evaluation  simulates  the 
authentication  of  a  client  to  one  or  more  servers  within  a  single  process.  All  communication 
between  parties  occurs  through  bytestreams  as  if  they  were  sent  over  the  network.  Both 
the  authentication  time  for  a  single  client  and  the  amount  of  data  transmitted  during  this 
authentication  were  recorded.  All  client  and  servers  keys  derive  from  a  common  2048-bit 
DSA  key.  For  both  DAGA  and  LRS,  the  number  of  clients  varied  from  2  to  32768  by  powers 
of  2.  Only  DAGA  depends  on  more  than  one  server  for  authentication.  Both  the  LRS  and 
DAGA  depend  on  a  linkage  context.  For  this  evaluation,  we  assume  that  the  administrators 
of  the  authentication  systems  have  agreed  upon  and  distributed  the  linkage  context  along 
with  the  set  of  the  group’s  public  keys. 


Figure  2d  shows  the  total  system  traffic  during  a  single  client  authentication  for  the 
various  forms  of  authentication  and  group  configurations.  The  traffic  results  have  been 
broken  down  into  client  to  server,  server  to  client,  and  server  to  server  traffic  in  figures  [2a] 


2b|  and  [2cJ  respectively.  As  expected,  pre-exchanged  key  authentication  does  not  depend 
on  the  number  of  clients  in  the  group.  DAGA  authentication  transfers  more  data  in  all 
three  cases  and  uniquely  has  the  requirement  that  servers  communicate  with  each  other 
during  an  authentication.  LRS  authentication  involves  a  non-interactive  zero  knowledge 
proof,  therefore  has  constant  traffic  from  server  to  client.  Finally,  all  forms  of  DAGA  traffic 
grow  linearly  in  the  number  of  clients  and  nearly  linearly  in  the  number  of  servers,  while 
only  LRS  client  to  server  traffic  grows  linearly. 


The  time  for  authentication,  Figure  2e,  exhibits  similar  characteristics  to  that  of  the 
traffic  for  the  respective  authentication  techniques.  In  this  scenario,  however,  unlike  traffic, 
DAGA  and  LRS  computation  time  remain  competitive,  particularly  when  using  4  or  less 
DAGA  servers. 

While  DAGA  compares  well  with  other  anonymous  authentication  schemes,  like  LRS, 
the  performance  concerns  remain.  In  order  to  remain  anonymous  among  k  individuals, 
anonymous  authentication  systems  traditionally  require  linear  computation.  Using  more 
efficient  DSA  keys,  such  as,  those  derived  from  elliptic  curves,  would  reduce  computation 
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Message  Size  in  Kilobytes 


2  8  32  128  2048  32768 


2  8  32  128  2048  32768 

Number  of  Group  Members 


(a)  Client  to  Server  Traffic  (b)  Server  to  Client  Traffic 


(c)  Server  to  Server  Traffic 


—  DAGA  -  32  Servers 
DAGA  - 1 6  Servers 
—  DAGA  -  8  Servers 
-  DAGA  -  4  Servers 


(d)  System  Traffic 


DAGA  -  2  Servers 
LRS 

Pre-Exchanged  Keys 


(e)  Authentication  Time 


Figure  2:  Time  and  traffic  comparison  among  DAGA,  LRS,  and  pre-exchanged  key  authen¬ 
tication 
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and  traffic  load  for  these  style  of  protocols  including  DAG  A  and  LRS. 


8  Security  Properties  and  Analysis 

This  section  describes  and  analyzes  DAGA’s  security  properties. 


8.1  Assumptions 

We  assume  that  the  Discrete  Logarithm  (DL)  and  Decisional  Diffie-Hellman  (DDH)  assump¬ 
tions  hold,  that  is,  any  probabilistic  polynomial  algorithm  solves  the  DL  problem  and  the 
DDH  problem  respectively  only  with  a  negligible  probability  [5|.  DAG  A  assumes  a  cyclic 
multiplicative  group  Q  of  prime  order  q ,  where  p  =  2q  +  1,  where  the  Discrete  Logarithm 
and  Decisional  Diffie-Hellman  assumptions  hold  in  Q  [5], 


8.2  Properties  of  the  Proofs  of  Knowledge 

In  this  section  we  show  that  the  client’s  and  server’s  proofs  of  knowledge  have  the  properties 
of  completeness,  special  soundness  and  special  honest-verifier  zero-knowledge  22  .  Note  that 
R  is  modeled  as  a  random  oracle. 

Definition  1  (E-protocol  ||22|) .  A  protocol  V  is  said  to  be  a  ^-protocol  for  relation  R  if: 


P  is  of  the  3-move  form,  and  if  P,  V  follow  the  protocol,  the  verifier  always  accepts 
(completeness). 

From  any  x  and  any  pair  of  accepting  conversations  on  input  x,  [t,c,r),  ( t,c',r ') 
where  c  A  d ,  one  can  efficiently  compute  w  such  that  ( x,w )  e  R  (special  soundness). 


•  There  exists  a  polynomial  time  simulator  Szk,  which  on  input  x  and  a  random  e  outputs 
an  accepting  conversation  of  the  form  ( t,c,r ),  with  the  same  probability  distribution 
as  conversations  between  the  honest  P,  V  on  input  x  (special  honest- verifier  zero- 
knowledge)  . 


8.2.1  pj^chent.  Client’s  Proof  of  Knowledge 


Completeness.  If  a  prover  and  verifier  faithfully  follow  the  protocol  on  common  input  C 
and  prover’s  private  input  x,  then  the  verifier  always  accepts  the  proof  generated  by  the 
prover.  Assume  that  the  proof  Pq  is  generated  by  a  client  i  who  knows  a  solution  Xi,  his 
private  key,  and  s,  the  product  of  all  secrets  shared  with  the  servers.  The  verifier  checks 
the  commitment  t  and  the  challenge  cs.  For  client  i,  the  commitment  verification  proceeds 
as  follows. 


U.  o  =  x?gri* 

U.  10  = 

iVi0  =  X?gri0 

gVil  =  s%c 7ril 

,vi.o  =  gCiXigVi.o-axi 

„Vi.l  _  UCiS  Vi.l-CiS 

y  —  ni  y 

{Vi. 0  _  gCiXi  Vi.o g-CiXi 

gVi.l  =  gCiS  gVi.i  g-Oi 

{Vi.  0  _  gVi.O 

to 

c2 

II 

to 

e 
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'Ci 


U.n  =  T0% 
hfA  =  Tgh?-1 
h?-1  =  KfishfifiA~CiS 
h\iA  =  h^h^hfi^3 
hfA  =  hvfiA 

For  every  client  j  V=  i,  the  commitment  verification  proceeds  as  follows. 


/./.()  =  Xc/gr^ 

tj.  10  =  S2gr-' 

o 

*05 

* 

II 

o 

■r-1 

£ 

Sm  gVj  l  =  S';,igr' ' 

Xy‘gv>"  =  Xy’  gVi" 

Gwj  nvj.l  _  Qwi  nVj.  l 

<jm.  g  —  c>m  g 

tj.n 

—  r‘  //  • 1 

-  i0  ni 

7 -Iw3  UVj  l 

1 0  nj 

r-pCj  j  f'j.l 

=  To  hj 

rnwj  Uvj  l 

1o  nj 

—  rrwi  hv^A 

-  J0  ni 

The  challenge  verification  proceeds  as  follows. 


? 

cs  =  c 

n 

CS  =  Xj  °j 
i= 1 

k  k 

Cs  =  YjWk  +  cs  -  2  Wk 
1=1  1=1 

C-s  =  Cs 


As  shown  above,  the  verifier  will  be  able  to  successfully  verify  the  commitments  t  and  c 
based  on  the  challenge  cs,  hence,  the  proof  is  complete. 

Special  Soundness.  Given  common  input  i  and  two  transcripts  of  successful  conversa¬ 
tions  (t,c=  (ci, . . . ,  Cn),  r  =  (ri, . . . ,  rn))  and  (t,  d  =  (d1, . . . ,  dn),r'  =  (r[, ...,  rn)),  where 
c  ¥=  d,  client  i’s  private  input  Xi  and  s  can  be  successfully  computed  as  follows: 


V%.  0  —  0  C-iXi  T%j\_  —  Vi.l  CiS 


r'i. o  =  Vi.o  -  d^i 


Xi  = 


ri. 0  -  Go 
a  —  d- 


r'i.i  =  vi- 1  -  c'is 
ri.  i  -  r'  , 

S  =  - T1 

Ci-Ci 


Special  Honest  Verifier  Zero-Knowledge.  There  exists  a  polynomial  time  simulator  Szk, 
which  on  common  input  I  generates  a  conversation  transcript  that  is  computationally  indis¬ 
tinguishable  from  a  transcript  generated  by  a  prover.  The  simulator  Szk  works  as  follows: 


1.  Choose  w i, . . . ,  wn  Sr  Z*  for  all  i  and  ui.o,  »u, . . . ,  vn.o,  vn.\  Er  Z*  for  all  i.  Compute 
commitments  U.o  =  X™lgVi  0,  ti. io  =  S1fi,gVtA ,  and  t*.ii  =  Tq  '  III'- 1  for  each  i. 

Set  t  =  (ti.o,  ti.io,  C.n,  •  •  • ,  tn. o,  tn. io,  tn.ii), 
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2.  Compute  cs  =  J^k=i  wk-  Set  c*  =  Wi  for  each  i  and  set  c  =  (ci, . . . ,  cn). 

3.  Compute  responses  r  =  (?’i.o,n.i,  •  •  • ,  using  rt,k  =  Vi,k  for  all  1  <  i  <  n  and 

ke  {0,1}. 

4.  Set  P  =  (cs,  t,  c,  r). 


The  verification  of  the  proof  works  as  follows  for  every  i: 


U.  o  =  X?gr*-° 
XpgVi0  =  X?gri0 


+  .  in  —  c<h  n.i 

“i.  10 

cmnVi.  1  _  QCi  r».i 

y  ^ my 


Ywinvi.O  —  YWi  nvi- 0  Qwi  nvi.l  —  Qwi  nvi.. 

y  —  y  y  —  y 


ti.n 

rTW i  lVi.  1 


—  TCihril 

~  10  ni 

'(■i:  i.r  i.l 


rpWiUVi.t  _  rpdj 

10  ni  —  ni 


? 

Cs  = 


n 

2 Cfc- 
fc=l 
n 


7;'  -1  =  C'/j! 


0 


2  =  2 


fc=l 


= 

fc=l 


8.2.2  pk server.  pr0ving  correctness  of  its  work 


Completeness.  The  verifier  reconstructs  the  commitments  as  follows: 

./  _  rpr  1  rp—T2 


=  T. 


Vl-CTj  j,-(v2~CSj) 


3- 1 

_  rj~\V\  rri  ^ j  rrt — 

~  .i  i  1j  i  .i  .i 

_  /TiVl  rji—V 2 

“  .i  i 

=  t\ 


t‘ 2  =  9riR) 


j ./  Qr2  oc 

^3  —  °7-lDj 


=  gv'~cr:i  gcri 


syV2  CSj  syCSj 

=  S3~1  S3- 1 


=  gVlg-crjgcri  = 


=  g 

=  t‘2 


3-2  J-t  3- 
=  S?-2 
=  h 


Given  that  t\  =  t\ .  t2  =  t-2  and  t'3  =  ks,  we  have 


c  =  H (Tj_i ,  Tj ,  Rj ,  g,  Sj ,  Sj.i ,  ^ ,  t'2 , 4) 
c  =  c 


Special  Soundness.  Given  common  input  z  and  two  transcripts  of  successful  conversa¬ 
tions  (ti,t2,tz,  c,  r\ ,  v2)  and  ki ,  c' ,  r^),  where  c/cf,  server  j’s  private  input  and 
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Sj  can  be  successfully  computed  as  follows: 

r\  =vi-  ci)j  r2  =  v2  -  CiSj 
r[  =  vi-  c'yj  r2  =  v2-  cts3 

r\  —  r\  r2  —  r2 

rj  =  - r  si  =  - T 

c  —  c  c  —  C 

Special  Honest  Verifier  Zero -Knowledge.  The  simulator  Szk  accepts  h  as  input  and 
performs  the  following  steps  to  produce  Pj  =  P: 

1.  Choose  v\,v2  Sr  Z*. 

2.  Set  c  =  h. 

3.  Calculate  t\  =  T]lxT~v\t2  =  gv'  t:i  =  S]!^. 

4.  Set  ?’i  =  ui  and  r2  =  v2. 

5.  Set  P  =  ( ti,t2,h,c,ri,r2 ). 

The  verification  of  the  proof  works  as  follows: 

A  =  Tj^T~^  tr2  =  griRj  A 

_  rpVl  rp—V2  _  V\  pC 

“  ~  9 

=  t\  =t2 

? 

Then,  we  verify  the  challenge  c  =  h,  which  gives  h  =  h. 

8.2.3  PK2erver:  Exposing  a  misbehaving  client 


_  Qr2  QC 

- 

_  qv  2  qc 

=  t3 


Completeness.  The  verifier  reconstructs  the  commitments  as  follows: 

A  =  grY? 


A  =  zrzcs. 

=  Zv~cyiZcyi 
=  ZvZ~cyiZcyi 

=  zv 

=  h 


=  gv-cyigcyj 

=  gvg~CVigcyi 
=  gv 

=  t2 


Given  that  t\  =  t\  and  t2  =  t2, 


c  =  H(ZSj ,  Z,  Yj,g, 

T~L{ZSj,  Z,Yj,  g,ti,t2)  =  U{ZS:t,Z,Y3,g,t\,t!2) 
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Special  Soundness.  Given  common  input  i  and  two  transcripts  of  successful  conversa¬ 
tions  (ti,t2,  c,  r)  and  c' ,  r'),  where  c  A  c' ,  server  j’s  private  input  y-j  can  be  successfully 

computed  as  follows: 

r  =  v  -  ayj 
r'  =  v  -  c'iVj 
r  —  r' 


Special  Honest  Verifier  Zero-Knowledge.  The  simulator  Szk  accepts  h  as  input  and 
performs  the  following  stepts  to  produce  Pj  =  ( ZSj,P ): 

1.  Choose  v  Er  Z*.  Calculate  c  =  h. 

2.  Calculate  t,\  =  ZVZCS.  and  t2  =  gvY?. 

3.  Set  r  =  v 

4.  Set  P  =  (h,t2,c,r). 

The  verification  of  the  proof  works  as  follows: 

t'i  =  ZrZcSj  t'2  =  grY f 
=  ZVZCS.  =  gvYf 
=  t\  =  t2 

Then,  we  verify  the  challenge  as  follows: 

c  =  h 
h  =  h 


8.3  Completeness 

We  require  that  servers  accept  a  properly  formed  authentication  request  from  every  honest 
client  i  who  belongs  to  a  group  G  defined  by  a  particular  authentication  context  C,  unless 
the  protocol  is  aborted  because  of  a  discovered  misbehavior  of  some  server.  A  client  i 
belongs  to  a  group  G  if  he  knows  a  private  key  xt  such  that  X*  =  gXi  e  X. 

Definition  2.  An  authentication  protocol  offers  the  completeness  property,  if  for  any  client 
ie  G  =  (X,Y)  who  correctly  follows  the  prescribed  protocol,  the  servers  accept  i  ’s  authen¬ 
tication  request  with  an  overwhelming  probability. 

Theorem  1.  DAG  A  offers  the  completeness  property. 

Proof.  Under  our  assumptions,  a  client  i  belongs  to  a  group  G,  is  in  a  possession  of  a  private 
key  Xi  such  that  Xi  =  gXi  and  X%  6  X.  Further,  we  assume  that  i  is  in  possession  of  a  well- 
formed  authentication  context  C  =  (G,  R ,  H,p,  g)  where  G  =  (. X ,  Y)  is  the  group  definition, 
H  =  (hi, ... ,  hn)  is  a  set  of  per- round  generators  for  clients,  and  R  =  (R\, . . . ,  Rm)  is  server- 
published  randomness.  From  the  trust  model  it  follows  that  all  servers  participate  in  the 
round  and  all  server’s  but  one  can  behave  arbitrarily  dishonestly. 
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In  order  to  make  an  authentication  request,  a  client  i  must  prepare  an  authentica¬ 
tion  message  =  {C,S,Tq,Pq),  where  C  is  the  authentication  context,  S  =  ( Z,S  = 
So,...,Sm)  consists  of  the  client’s  ephemeral  public  key  and  the  set  of  client’s  commit¬ 
ments,  Tq  is  the  initial  linkage  tag,  and  Po  is  a  proof  of  correctness  for  To.  We  will  show 
that  client  i  is  able  to  produce  a  valid  message  M  ■*  and  that  this  message  will  be  accepted 
by  the  servers  and  therefore  result  in  an  accepted  authentication  request. 

To  produce  a  valid  message  M°,  client  i  needs  to  produce  all  of  its  components. 

•  Authentication  context  C.  Client  i  obtains  C  before  making  an  authentication  request. 

•  Ephemeral  key  and  commitments  S .  Client  i  can  produce  S  since  it  depends  on  V s 
randomly  chosen  key  and  information  included  in  C. 

•  Linkage  tag  Tq.  The  tag  To  =  /i’si's2""s,ri  depends  on  i’s  publicly  available  per-round 
generator  hi  and  secrets  s\,  S2,  ■  ■  ■ ,  sm  created  in  the  previous  step. 

•  Proof  Po-  The  proof  To  depends  on  the  knowledge  of  X{  and  s.  Based  on  the  complete¬ 
ness  property  of  the  underlying  proof  of  knowledge,  a  client  i  can  always  produce  a 
valid  proof  if  he’s  in  possession  of  the  private  information  he  tries  to  prove  knowledge 
of.  In  our  case,  i  creates  a  proof  of  knowledge  PK(xi,s),  where  X{  is  i’s  private  key 
and  s  =  S1S2  ■  •  •  sm. 

Therefore,  i  can  produce  a  valid  message  =  (C,  S,  Tq.  Pq).  Now,  we  will  show  that 
this  message  will  be  accepted  by  the  servers  with  an  overwhelming  probability  and  therefore 
result  in  an  accepted  authentication  request. 

After  creating  M^1,  i  sends  it  to  an  arbitrarily  chosen  server  j.  Each  server  j  verifies  the 
message  M'1  and  either  (i)  accepts  it  and  produces  an  outgoing  tag  T-  and  a  proof  P k* er”er'; 
of  correctness  of  its  own  work  or  (%%)  rejects  it  and  produces  a  proof  p~K^erverj^  Qf  the  client 
i’s  misbehavior.  By  the  soundness  property  of  the  underlying  proof  of  knowledgePKg6™^, 
none  of  the  servers  can  expose  i  as  dishonest  and  therefore  reject  i’s  authentication  request, 
except  with  a  negligible  probability,  given  that  i’s  is  valid.  By  the  soundness  property 
of  pj^er,,er ;  none  of  the  servers  can  produce  a  valid  proof  of  correctness  if  they  did  not 
follow  the  protocol,  except  with  a  negligible  probability.  Therefore,  if  the  protocol  is  not 
terminated  and  a  faulty  server  discovered,  each  server  produces  a  valid  intermediate  tag  Ty, 
which  results  in  a  valid  final  tag  Tj.  Consequently,  i’s  authentication  request  is  accepted 
with  with  an  overwhelming  probability.  □ 


8.4  Soundness 


We  require  that  DAGA  is  a  sound  authentication  protocol,  that  is,  servers  only  accept 
properly  formed  authentication  requests  from  members  who  belong  to  a  particular  group  G 
as  defined  in  an  authentication  context  C.  This  means  that  it  should  offer  soundness  and 
not  allow  forgeries,  where  the  notions  of  forgeability  from 
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Typically,  the  soundness  property  of  a  non-anonymous  authentication  protocol  is  defined 
with  respect  to  “legitimate”  users  that  have  established  credentials  with  a  verifier.  In  case  of 
DAGA,  we  define  legitimate  users  as  users  who  belong  to  a  particular  group  G.  Any  client 
that  possesses  a  correct  long-lived  well-known  key  pair  associated  with  a  non-anonymous 
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identity  can  belong  to  any  G,  even  without  their  knowledge.  This  is  true  because  any 
member  i  can  be  listed  in  G  if  their  public  key  is  publicly  available  since  there  is  no  action 
required  on  the  client’s  side  in  order  to  be  added  to  G.  We  assume  that  honest  clients  keep 
their  private  keys  secret  and  dishonest  clients  can  arbitrarily  share  their  private  keys.  In 
such  a  case,  we  note  that  if  i  is  in  possession  of  a  private  key  i  such  that  X%  =  gl  and 
X%  £  X,  then  i  can  successfully  impersonate  i  by  authenticating  as  a  legitimate  client  and 
does  not  violate  the  soundness  property. 

Definition  3.  An  authentication  protocol  offers  the  soundness  property  if  an  authentication 
request  from  any  client  i  f  G  is  rejected  with  an  overwhelming  probability. 

Theorem  2.  DAG  A  offers  the  soundness  property. 

Proof.  Assume  that  a  client  i  does  not  belong  to  a  group  G ,  that  is,  i's  public  key  A,;  is 
not  included  in  X.  Therefore,  i  does  not  know  any  x%  such  that  Aj  =  gXi  and  X%  e  A. 
To  successfully  authenticate  as  a  member  of  G ,  i  needs  to  prepare  a  message  M?  on  behalf 
of  some  is  G.  To  do  so,  i  must  prepare  a  valid  message  M~  =  (C.  S.  Tq,  Pq)  without  the 
knowledge  of  x%,  such  that  each  server  accepts  i’s  authentication  request. 

We  will  show  that  i  cannot  produce  a  valid  message  M?,  except  with  a  negligible  prob¬ 
ability,  and  each  message  M?°  i  can  produce  will  be  rejected  by  the  servers  because  of 
the  invalid  proof.  Hence,  i’s  authentication  requests  will  be  denied  with  an  overwhelming 
probability. 

In  order  to  forge  a  message  M.~°,  a  client  i  must  forge  its  individual  elements,  that  is 
C,  S,  T0  and  P0. 

•  Authentication  context  C .  C  is  publicly  available  and  so  i  has  access  to  a  valid 
authentication  context. 

•  Ephemeral  key  and  commitments  S.  Client  i  can  produce  a  valid  S  since  it  does 
not  depend  on  x%.  To  do  so,  i  chooses  z  Sr  Z*  and  calculates  S  =  ( Z,S ),  where 
S  =  So, ... ,  Sm,  since  it  only  depends  on  the  knowledge  of  z,  a  generator  g  and  the 
set  of  servers’  public  keys  Y  included  in  C. 

•  Linkage  tag  Tq.  To  calculate  the  tag  To  =  h~1S2'"Sm,  i  uses  hi  included  in  C  and  and 
secrets  si,S2,  ■  ■  ■  ,sm  created  in  the  previous  step. 

•  Proof  Pq.  The  last  piece  i  must  produce  is  the  proof  PKclient  which  depends  on  the 
knowledge  of  x%  and  s.  i  knows  one  of  the  secrets,  namely  s,  but  he  does  not  know 
client  i’s  private  key  x%. 

By  the  soundness  property  of  the  underlying  proof  of  knowledge  PKci*enti,  i  cannot 
produce  a  valid  proof  Po  on  behalf  of  some  i  s  G,  except  with  a  negligible  probability. 
Therefore,  i  must  forge  Po  and  create  an  authentication  message  Mj°  that  includes  the 
forged  proof.  By  the  anytrust  assumption,  there  exists  at  least  one  honest  server  and 
therefore  i’s  message  will  be  eventually  rejected.  If  i  can  forge  a  proof  Po,  however,  such 
that  each  honest  server  j  accepts  the  proof  as  coming  from  a  member  i  with  non-negligible 
probability,  then  i  must  be  able  to  find  x~  such  that  A*  =  gxt.  This,  however,  is  impossible 
under  the  Discrete  Logarithm  assumption,  except  with  a  negligible  probability.  Therefore, 
each  authentication  request  from  i  f  G  is  rejected  with  an  overwhelming  probability.  □ 
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8.5  Anonymity 

Informally,  we  want  to  ensure  that  an  adversary  cannot  guess  which  member  has  been 
authenticated  with  a  probability  greater  than  random  guessing.  We  will  show  that  DAGA 
provides  anonymity  under  the  Decisional  Diffie-Hellman  assumption  in  the  random  oracle 
model  [4] . 

We  argue  that  in  order  to  break  a  client  i’s  anonymity,  an  adversary  must  leverage  the 
linkage  tags  because  he  cannot  infer  the  client’s  identity  based  on  a  proof  PKciimf  under 
the  zero-knowledge  property  of  the  proof. 

An  adversary  cannot  infer  the  identity  of  a  client  based  on  a  proof  of  knowledge  'P¥Ahent 
because  the  proof  is  zero-knowledge  and  does  not  leak  the  identity  of  its  creator.  Conse¬ 
quently,  the  adversary  must  focus  on  the  initial,  intermediate  or  final  tags  of  a  particular 
client  in  hopes  of  discovering  the  client’s  identity.  After  observing  a  protocol  run,  the  ad¬ 
versary  sees  the  initial  tag  T0,  all  the  intermediate  linkage  tags  T-,  a  final  linkage  tag  Tj-, 
and  all  partial  intermediate  tags  of  the  servers  he  controls.  By  using  per-round  secrets  rj 
and  Sj  of  every  dishonest  server  j,  the  adversary  obtains  T0  =  h~h  and  Tj  =  hrA ,  two  tags 
protected  by  the  per-round  secrets  r h  and  Sh  of  an  honest  server.  For  simplicity,  assume 
that  there  are  only  two  clients  {i,j}  e  G,  hence,  the  adversary’s  goal  is  to  decided  whether 
i  =  i  or  i  =  j  based  on  the  tags  he  obtained  but  without  the  knowledge  of  either  Sh  or  r /l. 
Because  both  hi  and  hj  are  generators  of  Q,  then  both  generators  generate  the  entire  group 
Q  when  raised  to  x  e  {1, . . . ,  q}.  Therefore,  h^h,  hs-h  e  Q  as  well  as  h^h ,  hr-h  e  Q,  and  each 
element  is  a  random  and  indistinguishable  element  of  Q.  Moreover,  by  the  properties  of  Q, 
there  exists  si,  S2,  q,  ^2,  hi,  hi  e  Q  such  that  h?1  =  h'J2  and  hA  =  h’2,  hence,  the  tag  can  be 
created  with  respect  to  hi  and  hj  equally  likely. 

Definition  4.  An  authentication  protocol  is  anonymous  if  for  any  probabilistic  polynomial 
time  adversary  A,  the  probability  p(n)  that  A  wins  the  anonymity  game  is  negligible  s.t. 

|  p(n)  —  1 1  =  negl(n). 

The  following  anonymity  game  is  played  between  the  adversary  A  and  the  challenger  C. 

1.  The  challenger  C  randomly  generates  all  private  and  public  keys  for  every  client  i  e  G 
and  for  every  server  j  e  G,  (Aj  =  gXi,xf)  and  ( Yj  =  gVj  ,Uj)  respectively. 

2.  The  adversary  chooses  two  honest  members  i  and  j,  both  of  which  belong  to  G. 

3.  The  challenger  gives  the  adversary  the  public  keys  of  all  clients  and  all  servers,  and 
the  private  keys  of  the  n  —  2  dishonest  clients  (G\{i,  j})  and  m  —  1  dishonest  servers. 

4.  The  adversary  is  allowed  to  run  the  protocol  polynomially-many  times  for  any  member 
keG\{i,j}. 

5.  The  challenger  chooses  a  bit  be  {0, 1}  uniformly  at  random.  If  b  =  0,  then  the 
challenger  chooses  member  i  to  participate  in  the  protocol  and  chooses  member  j 
otherwise. 

6.  The  challenger  participates  in  the  authentication  protocol  playing  the  role  of  all  honest 
servers  and  the  chosen  honest  member.  The  adversary  participates  in  the  authentica¬ 
tion  protocol  playing  the  role  of  the  dishonest  members  and  the  dishonest  servers. 
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7.  After  the  challenge  protocol  run,  the  adversary  is  allowed  to  run  the  protocol  poly- 
nomially  many  times  for  any  member  k  e  G\{i,j}.  Finally,  the  adversary  outputs  his 
guess  V  =  {0, 1}.  The  adversary  wins  the  anonymity  game  if  b'  =  b. 

Theorem  3.  DAGA  offers  the  anonymity  property. 

We  will  show  that  if  there  exists  a  polynomial  time  adversary  „4.AN0N  that  breaks  the 
anonymity  property  with  non-negligible  property,  then  we  can  use  this  adversary  to  create 
an  adversary  <ADDH  that  solves  the  Decisional  Difhe-Hellman  problem  with  non-negligible 
probability. 

Proof.  An  adversary  A  has  two  choices  for  his  behavior:  (1)  A  can  play  the  role  of  the 
dishonest  entities  and  deviate  from  the  protocol  in  an  arbitrary  way,  or  (2)  A  can  follow 
the  prescribed  protocols  and  try  to  break  the  anonymity  property  by  observing  the  protocol 
runs.  Briefly,  DAGA  requires  that  each  entity  produces  a  proof  of  correctness,  hence,  if 
the  adversary  does  not  follow  the  protocol,  he  will  fail  to  produce  the  required  output  by 
the  soundness  property  of  the  underlying  proofs  of  knowledge,  and  the  protocol  will  abort. 
Therefore,  in  order  to  break  the  anonymity  property,  A  follows  the  prescribed  protocols. 

Assume  that  there  exists  a  probabilistic  polynomial  time  A.Anon  that  breaks  the  anonymity 
property  with  a  non-negligible  probability  and  therefore  has  a  non-negligible  advantage 
Canon  hi  the  anonymity  game.  We  will  show  that  if  „4.AN0N  exists,  then  we  can  use  Aan0n  as 
a  subroutine  to  another  probabilistic  polynomial  time  adversary  ADDH  that  solves  the  DDH 
problem  with  non-negligible  probability. 

A,Ddh  plays  the  DDH  game,  receives  a  challenge  tuple  {g,ga,gb,gc)  from  the  DDH  chal¬ 
lenger,  and  outputs  0  if  ( ga,gb,gc )  is  a  Difhe-Hellman  tuple,  that  is  c  =  ab ,  otherwise  -4.DDH 
outputs  1.  Addh  uses  k4an0n  as  a  subroutine  and  therefore  must  simulate  the  .4.  anon’s  view 
of  its  interaction  with  the  challenger  in  the  anonymity  game.  Because  all  the  client’s  and 
server’s  proof  of  knowledge  are  zero-knowledge,  „4.DDH  can  efficiently  simulate  all  proofs  in 
the  random  oracle  model  |4|.  Therefore,  we  omit  the  proofs  in  the  description  below  keeping 
in  mind  that  they  can  be  simulated  and  correctly  verified.  ADdh  simulates  the  view  of  *4.ANOn 
as  follows. 

Step  1:  -4Ddh  creates  an  authentication  context  C  as  prescribed  in  the  protocol  except 
that  he  uses  ga  from  the  DDH  challenge  tuple  as  the  public  key  of  the  honest  server  h. 
TDdh  sets  the  generator  g  of  C  to  be  the  same  as  g  from  the  DDH  tuple. 

Step  2:  A-ddh  proceeds  to  simulate  the  initial  linkage  tag  Tq  by  first  setting  gb  from  the 
DDH  tuple  as  the  client’s  ephemeral  key  Zt.  Now  ADDH  generates  an  ephemeral  secret  s & 
for  every  server  k  A  h  as  follows:  Sk  =  T~L((gb)Vk),  which  he  can  do  because  he  possesses 
all  private  keys  of  dishonest  servers,  and  ADdh  uses  gc  for  the  ephemeral  secret  Sh  client  i 

Flm-  $k 

shares  with  the  honest  server  h.  Then,  *4DDH  generates  the  initial  linkage  tag  Tq  =  h\lk~l 

Step  3:  For  every  server  k  ^  h,  ADdh  processes  the  tag  Tq  as  prescribed  in  the  protocol. 
For  server  h,  -4.DDH  uses  gc  for  Sh  and  Th  =  {Th_1)^~Sh^Th\  finally  outputting  a  final  linkage 
tag  Tj. 

Now,  that  Tddh  correctly  simulated  the  view  of  Aan0n,  -^anon  outputs  his  guess  frAN0N  e 
{0, 1},  which  .4DDh  copies  and  outputs  as  his  own  guess  b'mn  =  6AN0N. 

*4ddh  correctly  simulates  the  view  of  the  challenger  in  the  anonymity  game  with  proba¬ 
bility  \  when  the  challenge  tuple  is  a  Diffie-Hellman  tuple.  Hence,  „4,DDH’s  advantage  is  \  of 
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the  advantage  of  A\non-  Following  our  assumption,  -4Anon  has  a  non- negligible  advantage 
Canon  in  the  anonymity  game  and  therefore  Addh’s  advantage  eDDH  =  which  is  also 

non-negligible.  Hence,  a  contradiction.  □ 


8.6  Forward  anonymity. 

Informally,  an  authentication  protocol  is  forward  anonymous  if  an  adversary  cannot  break 
any  client’s  anonymity  even  if  the  adversary  is  in  possession  of  some  (or  even  all)  group 
members’  private  keys  obtained  after  the  protocol  round  completed.  Recall  that  a  protocol 
run  is  defined  in  terms  of  an  authentication  context.  The  reason  that  we  can  only  ensure 
forward  anonymity  after  the  protocol  round  has  ended  is  because  an  adversary  who  pos¬ 
sesses  the  private  keys  of  the  clients  can  run  the  protocol  himself  using  some  private  key  Xi, 
successfully  impersonating  a  client  i.  After  a  successful  authentication  request,  the  adver¬ 
sary  would  learn  the  final  linkage  tag  Tj  that  would  allow  him  to  distinguish  all  previous 
authentication  requests  made  by  i  as  the  linkage  tag  persists  throughout  the  protocol  round. 


Definition  5.  An  authentication  protocol  is  forward  anonymous  if  for  any  probabilistic 
polynomial  time  adversary  A,  the  probability  p(n)  that  A  succeeds  at  the  forward  anonymity 
game  is  negligible  s.t.  \ p(n)  —  J,  \  =  negl(n). 

The  forward  anonymity  game  is  played  between  the  adversary  and  the  challenger  and 
is  exactly  as  the  anonymity  game  defined  in  the  previous  section  except  that  in  Step  7  the 
adversary  is  given  the  private  keys  ( Xi,Xj )  of  both  honest  members. 

Theorem  4.  DAGA  offers  the  forward  anonymity  property. 


Proof.  Following  that  DAGA  offers  anonymity,  we  know  that  an  adversary  Aanon  has  a 
negligible  advantage  in  the  anonymity  game.  The  only  difference  between  the  anonymity 
and  forward  anonymity  games  is  the  fact  that  *4.FA  receives  the  clients’  private  keys.  Because 
the  linkage  tags  and  per-round  generators  are  independent  of  the  private  keys,  Afa  can  at 
most  do  as  well  as  A.an0n  by  using  AAnon  as  a  subroutine  and  simply  not  using  the  private 
keys.  Hence,  *4.FA  advantage  eFA  =  eAN0N,  which  is  negligible. 

The  only  element  of  any  authentication  message  M0  that  depends  on  the  private  key  is 
the  proof  PKci*ent.  This  is  because  each  client  would  use  the  same  authentication  context 
C,  S  is  generated  based  on  z  e#  Z*  and  Y  e  C.  We  can  easily  show  that  a  proof  Po  from  M0 
could  have  been  produced  using  any  private  key  in  question  (xj  or  Xj).  and  the  knowledge 
of  both  keys  does  not  aid  *4,PA. 

Recall  the  prover’s  steps  to  prepare  ~PK.client  described  in  Section 
where  cs  is  the  random  challenge  t  and  c  are  the  sets  of  commitments,  and  r  is  the  set  of 
responses  as  follows 
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Po  =  ( cs,t,c,r ), 


1.  t  =  (H.0,H.10,H.11, ...  An.oAn.wAn.li)  for  each  i  e  G,  where  tlA)  =  XpgVi-°„  tiA0  = 
S%gVi  G  and  U.u  =  TphvA\ 

2.  c  =  (ci, . . . ,  Cn) ,  where 


Sn 

k= 1  Wk 

Wi 


for  i  =  i 
otherwise 
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3.  r  =  (ri.0,ri.i, . . . ,  r^.o, m),  where  rLk  =  vLk  -  CiXLk  for  all  1  <  %  n  and  k  e  {0, 1}, 
and  Xi.o  =  Xi.i  =  0  for  all  i  i,  xj.o  =  x$,  and  xn  =  s. 

We  observe  that  a  private  key  x*  of  some  prover  i  is  only  used  once  to  calculate  r%, o  = 
vt.o  —  CiXi  since  for  each  i  =£  i,  n. o  =  Hence,  in  order  to  decide  the  value  of  b,  Afa 

needs  to  decide  that  rk. o  for  some  position  k  is  equal  to  r%_ o,  where  i  e  {i,j},  in  which  case 
the  adversary  would  have  to  distinguish  an  element  of  form  o  —  cjxj  from  vk.o- 

However,  both  v^o  and  c.%  are  random  and  unknown  to  the  adversary  since  they  were 
securely  deleted.  Thus,  even  with  the  knowledge  of  x%,  all  elements  are  indistinguishable. 
Alternatively,  Afa  can  solve  each  r%. o  =  uio  —  c-ixi ,  using  both  xi  and  Xj.  In  this  case, 
however,  Afa  obtains  two  sets  of  valid,  and  therefore  indistinguishable,  solutions.  Hence, 
the  knowledge  of  the  private  keys  does  not  aid  the  adversary.  □ 

8.7  Proportionality 

Intuitively,  the  proportionality  property  ensures  that  within  an  authentication  context  C 
each  client  i  can  authenticate  only  once  as  a  particular  anonymous  client  and  each  subse¬ 
quent  authentication  request  within  the  same  context  will  be  recognized  as  coming  from 
that  client.  Therefore,  the  verifier  will  be  able  to  recognize  when  the  same  client  authenti¬ 
cates  but  without  knowing  that  client’s  identity.  We  achieve  this  property  by  assigning  a 
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unique  linkage  tag  Ti  =  3  to  each  client  i  in  a  way  that  ensures  that  the  tag  is  always 

the  same  for  each  authentication  request  within  the  same  context  C. 

The  linkage  tags  enjoy  an  additional  property  of  unlinkability  between  different  authen¬ 
tication  contexts.  That  is,  the  same  client  i  receives  a  different  and  unlinkable  tag  Xy  within 

some  context  C*2  as  long  as  Cj  A  C2  such  that  R  e  C\  A  R  £  Ci-  This  property  is  important 
to  ensure  that  clients  remain  anonymous  and  unlinkable  even  after  performing  authentica¬ 
tions  within  different  authentication  contexts.  It  is  straightforward  to  see  that  two  linkage 
tags  of  client  i  from  two  different  contexts  are  two  independent  elements  of  the  underlying 
group  Q. 

Definition  6.  An  authentication  protocol  offers  the  proportionality  property  if  each  member 
i  receives  exactly  one  unique  final  linkage  tag  Tj  within  the  same  authentication  context  C . 

Theorem  5.  DAG  A  offers  the  proportionality  property. 

Proof.  We  will  show  that  each  client  i’s  final  linkage  tag  is  unique,  and  that  during  each 
authentication  within  the  same  authentication  context  C,  i’s  final  linkage  tag  is  the  same. 

First,  however,  we  will  consider  the  constraints  placed  on  the  behavior  of  each  client  i 
and  each  server  j  by  the  fact  that  they  need  to  produce  a  proof  of  correctness  of  their  work 
and  other  assumptions.  By  the  soundness  property  of  the  underlying  proof  of  knowledge 
PK client  an(j  assumption  that  no  client  knows  x  such  that  gj  =  gf  for  any  i,j,  any  client 
i  must  generate  his  initial  linkage  tag  T0  with  respect  to  his  per-round  generator  hi.  That 
is,  T0  =  hf  for  some  s.  By  the  soundness  property  of  the  underlying  proof  of  knowledge 
PK  seiner  ^  g^p  server  j  must  correctly  remove  the  ephemeral  secret  Sj  assigned  by  a  client 
and  add  the  correct  server’s  ephemeral  secret  rj.  That  is,  each  server  j  calculates  Tj  = 

Tjf1  3 ,  where  sj1  is  a  multiplicative  inverse  (mod  q )  of  -Sj  =  H(Zyj)  and  rj  =  logg(Rj). 
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Each  client’s  final  linkage  tag  is  unique.  The  fact  that  each  client’s  final  linkage  tag 
is  unique,  that  is,  Tj  7^  Tj  for  any  j  ^  i  £  G,  follows  from  the  basic  number  theoretic 

properties  of  Q.  Assume  the  contrary,  that  is  for  i,j  such  that  i  ^  j  Tj  =  Tj.  Then  it  must 
be  so  that  hj  =  hj  where  hi  ^  hj,  and  r  =  YXj=irj-  Because  hi  is  a  generator  of  Q,  then 
by  definition  every  element  of  Q  can  be  expressed  as  hf  for  some  x  e  {0, . . . ,  q  —  1},  where  q 
is  the  order  of  Q.  Then,  we  have  hj  =  hfr .  Consequently,  hj  =  hfr  only  if  r  =  xr  (mod  q). 
Because  \hf\  =  q ,  then  it  must  be  so  that  x  =  q.  Then,  r  =  qr  (mod  q)  and  r  =  r  (mod  q ). 
This  contradicts  the  assumption  that  hi  ¥=  hj. 

Each  client  i 's  final  linkage  tag  is  the  same  for  each  accepted  authentication  request.  The 
fact  that  each  client  i’s  final  linkage  tag  is  the  same  is  straightforward.  Assume  two  distinct 
authentication  requests  from  i  using  the  same  C  that  result  in  two  initial  linkage  tags  T0  and 

where  each  s'  ^  s" .  The  servers  will  collectively  process 


T0  such  that  T0  =  hj 


and  T0  =  hj 


both  tags  as  follows:  Tj  =  (T0)s  lr  =  (hj  )s 


=  hj  and  T]  =  (T")s  "  r  =  (hj"Y 


=  hj. 


Therefore,  each  client  i  receives  exactly  one  unique  final  linkage  tag  for  each  accepted 
authentication  request.  □ 


8.8  Deniability 

The  deniability  notion  that  DAGA  provides  follows  the  zero-knowledge  notion  of  deniability 
first  formalized  in  the  context  of  authentication  in  |27i.  Informally,  we  can  say  that  an 
authentication  protocol  is  deniable  if  after  a  complete  protocol  run  there  is  no  proof  that 
any  client  participated  in  the  protocol  given  an  authentication  transcript  of  a  protocol  run 
and  all  public  information. 

The  notion  of  deniability  is  closely  related  to  anonymity,  however,  the  subtle  differences 
between  these  two  properties  might  make  a  significant  difference  and  make  a  protocol  that 
provides  both  properties  more  suitable  for  certain  situations  where  the  mere  fact  that  some 
client  from  a  particular  group  authenticated  anonymously  reveals  useful  information.  In 
case  of  anonymity,  an  adversary  should  not  be  able  to  tell  which  member  authenticated 
while  in  case  of  deniability  the  adversary  should  not  be  able  to  tell  whether  any  mem¬ 
ber  authenticated  based  on  the  authentication  transcripts.  We  can  achieve  anonymity  by 
ensuring  that  two  valid  transcripts  T  and  Tj  of  members  i,j  e  G  respectively  are  indistin¬ 
guishable  from  one  another.  On  the  other  hand,  we  achieve  deniability  by  ensuring  that  a 
valid  transcript  Tj  of  client  i  is  indistinguishable  from  a  simulated  transcript  Ts  that  was 
computed  without  the  help  of  any  member  i  e  G. 

DAGA  inherently  offers  a  weak  notion  of  deniability  in  the  sense  that  any  member  listed 
in  G  can  plausibly  deny  being  an  active  client  because  anyone  can  conscript  an  arbitrary 
group  G  using  publicly  available  public  keys  and  without  any  help  or  knowledge  of  the 
listed  members.  However,  as  pointed  out  above,  this  might  not  be  sufficient  because  the 
fact  that  a  valid  authentication  transcript  exists  implies  that  at  least  one  of  the  clients  in 
G  authenticated. 

DAGA  achieves  deniability  by  using  an  interactive  rather  than  non-interactive  zero- 
knowledge  proof.  This  is  because  an  interactive  proof  is  not  transferable  and  only  “con¬ 
vinces”  the  party  involved  in  the  proof.  In  a  non-interactive  proof  the  verifier  is  replaced 
with  a  hash  function  to  create  an  unpredictable  challenge  that  a  prover  cannot  anticipate 
in  advance.  Therefore,  anyone  at  any  point,  even  much  later,  can  verify  the  non-interactive 
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proof  and  be  convinced  (or  not)  that  the  prover  knows  his  secret.  This  property,  while 
useful,  goes  against  the  notion  of  deniability. 

Definition  7.  An  authentication  protocol  is  deniable  if  for  any  client  i  e  G  there  exists  a 
simulator  So  produces  a  transcript  TRsim  of  a  protocol  run  such  that  TRsim  is  indistin¬ 
guishable  from  a  real  transcript  TRi  that  resulted  from  i’s  run  of  the  protocol. 

Theorem  6.  DAGA  offers  the  deniability  property. 

Proof.  We  will  show  that  there  exists  a  polynomial-time  simulator  So  that  produces  a 
transcript  TRsD  that  is  computationally  indistinguishable  from  a  client  generated  tran¬ 
script.  We  assume  that  So  produces  a  transcript  “on  behalf’  of  some  client  i  using  an 
authentication  context  C  =  (G,  R ,  H ,p,  g )  without  the  knowledge  of  any  private  key  Xi  that 
corresponds  to  some  public  key  A*  e  X.  The  simulator  So  works  as  follows.  First,  So 
produces  a  linkage  tag  T0  using  the  client  i’s  prescribed  per-round  generator  hi  e  H  exactly 
as  client  i  would.  Since  So  has  all  required  information  (the  per-round  generator  ht  and 
the  product  of  all  ephemeral  secrets  shared  with  the  servers)  the  simulator  reproduces  the 
exact  tag  To  as  follows. 

1.  Choose  z  £r  Z*  and  compute  Z  =  gz . 

2.  For  each  server  j,  compute  Sj  =  H(Y J). 

3.  Compute  To  =  hfS2'"Srn.  Then,  for  each  1  ^  j  ^  m  compute  Sj  =  gSlS2---sj  such  that 
S0  =  g,  S1  =  gsf  ...,  Sm  =  g^2...smy  Set  §  =  (Z,S0, . .  .,Sm). 

At  this  point  So  has  computed  S  and  To-  Next,  S  must  produce  a  proof  To,  however, 
without  the  knowledge  of  i’s  private  key  Xi  (or  any  other  key).  To  do  so,  we  leverage  the 
fact  that  PKci*ent'  is  zero-knowledge  and  therefore  there  exists  a  polynomial-time  simulator 
Szk  that  produces  computationally  indistinguishable  transcripts  of  PKchenti.  So  uses  Szk 
as  a  subroutine  to  produce  To-  Szk  takes  as  input  the  authentication  context  C  and  works 
as  follows. 

1.  Choose  w\, . . . ,  wn  £r  Z*  for  all  i. 

2.  Choose  ui.0,ui.i,  •  •  -,vn.  0,vn.i  £r  Z*  for  all  i. 

3.  Compute  commitments  o  =  X'f]'gv%0 .  T  10  =  SffgViA,  and  tj.n  =  for  each  i. 

Set  t  =  (fi.o,  i  1.10 j  *1.11,  •  •  • ,  tn. o,  tn. 10,  tn.il), 

4.  Compute  cs  =  1  Wk- 

5.  Set  C{  =  Wi  for  each  i  and  set  C  =  (ci, . . . ,  cn). 

6.  Compute  responses  r  =  (?’i.o,n.i,  •  •  • ,  A.oTi.i)  using  rt,k  =  Vi±  for  all  1  <  i  <  n  and 
fee  {0,1}. 

7.  Output  P  =  ( C,R ). 
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After  obtaining  P,  Sd  sets  Po  =  P- 

It  is  straightforward  to  see  that  the  tag  produced  by  Sd  is  identical  to  a  tag  a  client  i 
would  have  produced,  hence,  it  will  be  accepted  by  servers.  Also,  the  proof  Po  is  correct 
and  can  be  successfully  verified  with  respect  to  the  simulated  challenge. 


Ti.o  =  Xf'gri0 

/,.!(>  =  S'wg’-- 

gvi.0  =  X?gri- 0 

qwinvi.i  _  qci 

y  ^ my 

gvi.o  =  xpgVi0 

qmnVi.  1  _  qWi  Vi. 

y  y 

n 

Ti.n  =  1 

Cs  ^  ^  j  Ck  • 

r  —  yr  / '•  .1 

ai  ~  10  ni 

k=l 

n  n 

UiLVi,  i  rpWiiVi.l 

ni  —  10  rli 

Zj  Wk  =  Xj  Wk 

k= 1  k— 1 

Finally,  Sd  prepares  an  authentication  message  Mo  =  (C,  S,  To,Po)  and  sets  TRsD  =  Mq. 

Now  we  argue  that  the  transcript  TRgD  =  (C.  S.  To,  Po)  is  computationally  indistin¬ 
guishable  from  a  client  generated  one. 


•  C ,  the  authentication  context,  has  an  identical  distribution, 

•  S,  client’s  ephemeral  key  and  commitments,  has  an  identical  distribution, 

•  To,  the  linkage  tag,  has  an  identical  distribution, 

•  Po  is  produced  by  a  simulator  Szk  that  produces  proofs  that  are  computationally 
indistinguishable  from  a  client  generated  one  as  the  underlying  proof  of  knowledge  is 
honest- veriher  zero- knowledge. 


□ 


8.9  Forward  Deniability 

One  of  the  goals  of  DAGA  is  to  retain  anonymity  even  under  the  exposure  of  the  clients’ 
long  term  private  keys.  This  raises  an  interesting  idea  to  apply  the  same  requirement  of 
forward  security  to  the  deniability  property.  That  is,  we  would  like  to  ensure  that  a  pair 
of  transcripts  TRsim  and  TRreai  generated  using  an  authentication  context  C,  remains  in¬ 
distinguishable  even  given  the  additional  knowledge  of  the  compromised  private  keys.  We 
call  this  notion  of  deniability  forward  deniability.  Intuitively,  forward  deniability  should 
hold  given  that  deniability  holds  as  we  were  able  to  show  that  we  can  generate  an  indistin¬ 
guishable  transcript  Tsim  without  the  knowledge  of  any  private  key.  The  proof  of  forward 
deniability  follows  similarly  to  the  proof  of  forward  anonymity  where  we  argue  that  the 
additional  knowledge  of  the  private  key  does  not  aide  the  adversary  in  distinguishing  the 
transcripts. 

Definition  8.  An  authentication  protocol  is  forward  deniable  if  for  any  client  i  a  simulated 
transcript  TRgD  remains  ( computationally )  indistinguishable  from  a  real  transcript  TRi 
that  residted  from  i ’s  run  of  that  protocol  even  given  a  private  key  Xj  of  every  client  j  e  G. 


34 


Theorem  7.  DAGA  offers  the  forward  deniability  property. 

Proof.  Assume  we  have  an  authentication  context  C  and  two  transcripts  TR{  and  TRgD 

— *  c» 

where  each  transcript  consists  of  an  authentication  message  Mg  =  C,  S,Tq,  Pq  and  MgD  = 
C',S',Tq,  Pq  respectively  created  using  C.  We  previously  argued,  in  the  proof  of  deniability, 
that  these  two  transcripts  are  (computationally)  indistinguishable.  Now  we  wish  to  revisit 
this  claim  and  verify  if  the  knowledge  of  all  private  keys  Xj  aids  to  distinguish  the  two 
transcripts. 

•  C  =  C'  are  identical  and  therefore  have  an  identical  distribution. 

•  S  and  S'  are  randomly  generated  based  on  z,  z'  £r  Z*  and  have  an  identical  distribu¬ 
tion,  and  do  not  depend  on  a  client’s  private  key. 

•  To  and  Tq  have  an  identical  distribution  and  also  do  not  depend  on  a  client’s  private 
key. 

•  To  is  produced  by  a  simulator  Szk  without  the  knowledge  of  any  private  key  and  Pg 
is  a  client  generated  transcript  using  his  private  key  x'j. 

Therefore,  the  only  element  of  the  transcript  that  could  be  affected  by  the  knowledge 
of  the  private  keys  is  the  proof  of  knowledge  Pq  as  Po  is  created  using  X{  and  Pg  without 
Xj.  Therefore,  we  observe  the  following  differences  in  the  set  of  responses  of  r  and  r'\ 
r,;.o  =  vi. o  —  CiXi  and  r'i0  =  v'i0.  In  order  to  distinguish  between  Pg  and  Pg,  it  must  be 
possible  to  distinguish  between  r,;.g  and  r'i0.  However,  both  v^. o  and  c*  are  random  and 
unknown  and  therefore  even  with  the  knowledge  of  Xi  rj.g  and  r\  0  are  indistinguishable.  □ 


9  Related  Work 


There  are  several  approach  to  realizing  anonymous  authentication,  a  broad  class  of  schemes 
offering  varying  sets  of  properties.  Some  of  them  focus  on  providing  properties,  such  as 
unlinkability  or  anonymity  revocation  by  a  third  party,  that  are  in  contradiction  to  the 
properties  DAGA  is  design  to  achieve. 

Group  and  ring  signatures  Group  signatures  (13,  20  allow  a  member  to  anonymously 


sign  a  message  on  behalf  of  a  pre-defined  group.  However,  user’s  anonymity  is  revocable 
by  a  group  manager.  Ring  signatures  001  25,50,51]  offer  greater  flexibility  by  allowing 
ad-hoc  group  creation  thereby  supporting  a  weaker  notion  of  deniability.  Linkable  ring 
signatures  [44,45]  and  short  linkable  signatures  [3,59  further  improve  upon  ring  signatures 
by  adding  linkability.  The  schemes  of  J3S  support  heterogeneous  keys. 


E-cash  E-cash  schemes  §01  16)  (T§]  are  designed  with  anonymity  (also  referred  to  as 
untraceability)  in  mind  and  often  achieve  deniability  as  well.  However,  normally  these 
schemes  prevent  double-spending  as  using  a  coin  twice  reveals  the  owner’s  identity,  rendering 
the  schemes  useable  for  one-time  authentication  only. 

Anonymous  credentials  The  credential  system  proposed  in  |l0|  allows  users  to  obtain 
credentials  from  organizations  and  later  demonstrate  their  possession  in  an  anonymous  and 
unlinkable  way  as  many  times  as  desired.  The  lack  of  linkability  was  later  addressed  by 
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one-time  credentials  [43]  in  form  of  coins  that  if  spent  twice  would  reveal  user’s  identity. 
The  schemes  proposed  in  |8,[4]][48j[58j  bridge  this  gap  and  offer  credentials  that  a  user  can 
show  up  to  k  times,  offering  limited  linkability  which  in  case  of  [8]  applies  to  certain  periods 
of  time. 


Other  schemes  Deniable  authentication  27  defines  the  idea  of  deniability  in  the  context 


of  authentication.  Their  notion  of  deniability  assures  that  the  protocol  does  not  leave  any 
paper  trail,  however,  the  scheme  is  not  anonymous.  Deniable  Ring  Authentication  |47 
combines  deniable  authentication  with  ring  signatures  [50 j .  While  it  offers  protection  against 
compromised  private  keys,  it  still  lacks  proportionality.  1 56, 57  makes  the  protocol  of  1 27 
non-interactive.  40  proposes  another  protocol  to  achieve  deniable  ring  signature,  however, 


the  deniability  property  is  viewed  as  non-frameability  of  honest  client. 


10  Conclusions  and  Future  Work 


DAGA  is  a  new  anonymous  group  authentication  protocol  that  offers  a  unique  set  of  prop¬ 
erties:  anonymity,  deniability,  and  proportionality  that  persists  even  in  a  case  of  private  key 
exposure.  Our  initial  evaluation  suggests  that  DAGA  compares  reasonably  well  to  LRS 
and  non-anonymous  authentication  given  the  functionality  gain,  however,  the  performance 
concerns  remain. 

Future  work  includes  extending  DAGA  to  handle  heterogeneous  keys,  use  batching 
techniques  for  proofs  of  knowledge  37  and  elliptic  curves  to  improve  performance,  and 


extend  the  current  implementation  to  a  fully  distributed  system. 
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